[Editor's note: This article, which looks at the interactions of software
projects and distribution providers, is presented in three parts.
introduces the issues downstream
distributions have with upstream software providers. Part 2
covers the technical needs of the
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.
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
- 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
- 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.
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
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.
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
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.
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.
to post comments)