Distribution-friendly projects Part 3 [LWN.net]

April 23, 2008

This article was contributed by Diego Pettenò

[Editor's note: This article, which looks at the interactions of software projects and distribution providers, is presented in three parts. Part 1 introduces the issues downstream distributions have with upstream software providers. Part 2 covers the technical needs of the distributions.]

Philosophical requests

The philosophical side of packaging is mostly of concern to the users, although the global goals of the distribution will have some philosophical issues as well. In this section I'll try to cover the most common requests of the downstream distributions to the various upstream providers.

Technical requests can usually be taken care of with compromises and options at build-time, so a solution will usually be found in time. Philosophical needs, on the other hand, often put distributions and original developers on two opposite positions, and cannot be fixed unless one of the two accepts the position of the other.

While technical needs are usually shared between distributions, different distributions have different goals, and in turn different philosophical needs, and this adds to the problem. A project wanting to accommodate the requests from a distribution might make life more difficult for another, that has different philosophical issues.

User expectations

Users of a distribution usually expect a certain behaviour from the software they install. For graphical applications, they also might expect a certain graphical aspect so that all the applications blend in together. These problems may be easier to solve as non-technical concerns go, as they usually require providing more choices.

One common example comes with fonts in graphical environments: most distributions these days ship with all the graphical applications set to use the same font family. This is done to follow the style rule of using as few different fonts in a single view as possible (you don't usually see a book using ten or twelve different fonts in the text). So one common request is for software to provide a way to change the default font without user intervention (which otherwise often involves changing the source code).

This still seems to be a technical issue; for example, using TrueType fonts requires the use of some sophisticated libraries for font rendering. Some projects don't want to complicate their code with them. Similarly, some distributions like to provide anti-aliasing for the default fonts, but some projects dislike the whole idea of using anti-aliased fonts.

A similar issue might arise with GUI toolkits. Distributions tend to provide the same graphical aspect for the software they install, this usually means that both GTK+ and Qt are set to a similar, if not identical, themes. So one other thing distributions might like is for graphical software to rely on a theme-capable toolkit. Themes and skin, though, are often disliked by minor projects, which might also not be using GTK+ or Qt toolkits, as they tend to make the code more complex and slow.

Users expect to be able to set their language preference and to have all applications use that language. Unfortunately adding support for translations is a far from trivial task, and adds complexity to the software, which is something that especially smaller software projects try to avoid. Similar complexity stems also from supporting text encoding like UTF-8, which - for certain distributions like Fedora - is a prerequisite for the software to be added to their repository.

It's easy to see that user requests are often pretty complex and hard to implement on many existing projects. The best way to make a project more appealing for distributions is to start from the beginning with these points in mind.

Distribution philosophical policies

There are also distribution policies regarding issues that are simply philosophical. In this category you can find the requests of distributions for removing code that deals with non-free formats, like most multimedia formats. All these issues are usually centered around licensing, copyright and patent-encumbered formats or algorithms:

Multimedia formats, video, audio or picture formats are often considered patent-encumbered (sometimes with the exception of Xiph formats like Ogg, Vorbis and Theora). Most distributions would like support for these to always be optional, for this reason. This might actually start to be a problem for multimedia applications as their main goal is just to provide support for these patent-encumbered formats.
Usage of GPL-incompatible libraries by GPL applications, and other forms of licenses mixing is a quite big issue for almost all binary distributions. Some distributions will not be able to legally redistribute packages with licensing issues. This is why distributions often push for optional support for GnuTLS as a replacement for OpenSSL, or build packages without SSL support by default. (In addition to license problems, SSL support is also encumbered with special cryptography legislation, which makes its handling even more a problem).
In both multimedia and cryptography there is the problem of patent-encumbered algorithms. Even when the format itself is not encumbered, the algorithm used to generate the result might be. Distributions want a way to opt-out some of the support in the software.
Support for network analysis tools can also be a problem. While the boundary between analysis and cracking can be quite thin, laws like the ones enacted in Germany start making it difficult for distributions to carry tools that are even well inside the definition of network analysis rather than network cracking.

For some distributions, there are extra policies that depend on the license used by the project itself. For instance if they disallow changes to the source (verbatim copy only) they might disallow the distribution from taking the proper steps to fix technical issues.

Each distribution has its philosophical goals, such as a focus on Free Software or a focus on corporate users. These goals will influence the distribution's view of philosophical issues. Companies tend to take a more defensive look at these issues than community projects. European projects tend to be more lax when it comes to software patent problems, and other countries don't enforce copyright laws. These are the types of factors that will affect a distribution's philosophical goals.

Conclusions

The issues described in this section can also conflict directly with the goals of the upstream project (and they often do), in which case the project is very unlikely to be packaged officially by at least some distributions.

This is why I categorized these issues under the philosophical name rather than technical. It's actually fairly common that issues of this kind sprout debates inside and outside projects and distributions, as developers and maintainers have very different feelings about them.

One example is a software package in which the team is composed entirely by native English speakers. Such a project has a fair chance to start without considering that some users might expect the user interface to be available in any other language. While this might sound a bit harsh, it's often true.

It is nearly impossible for a project to satisfy these issues altogether for every possible distribution. And it becomes even harder when the project itself focuses on keeping the code as simple as possible, even when that means ignoring features and optimizations that require adding complexity.

For this reason, the issues listed here have to be taken as suggestions, rather than requirements, depending on the original goals for the project. If the project wants to be widely accepted though, it will need to provide a good mitigation method for these issues.

Afterword

In addition to these issues, that relate directly with the source and the software, there are some extra suggestions that can be given to make the whole project friendlier to distributors, entailing process and workflow changes.

Making it visible in the source code who and where to send patches and suggestions is certainly a nice initial step. When preparing a patch for software that misbehaves, it's usually simpler to read the documentation shipped with the software. Distribution developers are less likely to open a browser to check the homepage of the software, looking for the address to use. This also means that you should always make sure to update your address referenced in the software documentation. If you change your email address, and the old one is no longer reachable, it is a good idea to re-roll the tarball even if no code changes are present (in these cases, adding a suffix to the tarball is better than changing the version).

Even better, having a public way to track patches is often useful: distributions can easily see if someone else fixed that issue before, and how. It might save a downstream maintainer some work, and it helps having a solution that works for more than one person at a time.

Acknowledging the patches, and pointing out what is not going to work, is something that helps reduce the frustration for maintainers, as it allows them to better suit the coding style of the project each time. Ignoring a patch entirely is not a good idea, as these patches are rarely non-issues.

It's also important to notice that almost always the patches don't concern optimizations. Most distributions are generally less concerned with the performance of the software over the correctness as defined by their own policies. Distributions would often prefer to reduce the speed of the software if that makes it better follow their policy. This has also to be understood and accepted, and at the best worked around by either improving the optimization, allowing an option, or by making a trade off.

Having a public repository for the source is often helpful, but often not in major ways. While it makes it easier for the downstream maintainers to check the progress of the code, it might not be trivial to identify where the correct source is. If the project uses branches it might well be that the upstream developers have already moved away from the broken code by the time a distribution tries to package it. If a repository is available, regular tagging and branching is helpful, and makes it easier for a maintainer to find what has actually changed between two or more versions.

Finally

This article cannot cover all the possible requests that a distribution might have, and it does not even get close to all the possible requests by all possible distributions. There are even more requests relating to portability, for distributions that target particular non-mainstream hardware (e.g. distributions targeting embedded device like OpenWRT) or distributions for other (Free and non-Free) operating systems (like Cygwin, Fink or FreeBSD ports). The remaining issues have to be coped with on an incremental basis, with collaboration of the downstream maintainers for that distribution.

Following these practices might make it easier for those people to contact the upstream developers to work out a solution. They make the project appear friendlier, just as well as saying Please let us know how we can improve your users' experience with our software. They change the mindset of a project so that it makes it less frustrating for packagers to prepare it for distributions. Going against all these points not only makes the job harder for the distributors, but might give the (wrong) idea that the project is not open to accommodating distributions.

(Log in to post comments)