The perl5-porters recently saw a rather acrimonious discussion on how the
Red Hat and Fedora distributions choose to package the Perl language and
associated modules. Things have calmed down (the parties have essentially
agreed to disagree), but an interesting issue remains: what can development
projects do if they're unhappy with how distributors are treating their
When Tom Christiansen gets irritated with somebody, one can generally be
assured that they will know about it. In this case, Tom let
the world know that he was not happy with the way Red Hat packages and
Perl. The complaint is that, if one installs "perl," one does not get the
entire Perl 5.10 distribution. Tom says:
Of these, the most egregious omission is CPAN.pm itself, as its
absence precludes the easy fix of using CPAN to grab what Redhat
forgot. Other pieces notably missing include Text::Harness and
h2xs -- although h2ph *is* included! Go figger.
As it happens, it is possible to get the entire 5.10 distribution; one
simply needs to install "perl-core" instead of plain "perl." Tom asserts that this
arrangement is confusing; "perl-core" should not be a superset of "perl";
the package called simply "perl" (which is what most users will install)
should be the thing that the Perl developers shipped. He says that
Red Hat's arrangement causes confusion, with users not knowing if they actually
have "Perl" or not.
Beyond that, it goes against the developers'
intent, which included providing users with all the basic modules they
needed from the outset. Many users, it seems, will not (or cannot) add
extension modules to their systems; the Perl developers tried to ensure
that these users would have a minimally-functioning system available to
them. But, alas:
But why did we bother? For all that effort is now undermined, even
unravelled, if now vendors choose to strip down the real Perl
distribution by paring away pieces that we've decided to ship. I
don't envy them their positioning themselves as forkers, doomed to
winnow and weed and forever maintain, but that's their own
problem. Worse is when they present this stripped minidistro as the
real thing. It's a misleading and confusing state of affairs which
should be discouraged.
Tom "spot" Callaway explained Red Hat's
At the time of the split, we had a LOT of packages which depended
on simply "perl". We also had a lot of people who wanted individual
perl modules updated that live within the "perl tarball", which is
a complicated task to undertake. By splitting the perl modules out
into separate subpackages we were at least able to allow people to
build newer RPMs. In addition, the split had the added benefit that
people who did not need nor want all of the components built with
perl could get a system without them. This lowered the default
Fedora installation footprint.
Tom says that the package naming could be changed, but that would have a
number of unfortunate effects on users. That said, there are some
possibilities for improving the situation, but the best course is not
entirely clear. Tom Christiansen was not
completely happy with the explanation, but he also seemed to understand
the pressures which led to Red Hat's way of doing things.
In the near term, it looks like things will
not change a whole
lot be changing; see this comment for details. But
we're likely to see this kind of debate come back in the future. Distributors
serve as a sort of middleman, tweaking and refining upstream packages in
ways which they think improve things - either for their users or for themselves.
Distributor changes can include splitting up the package (as with Perl),
removing user-unfriendly messages (as has happened with cdrtools), making
the software more consistent with the rest of the distribution, fixing
security problems, removing software seen as legally problematic, and so
on. It's part of what distributors do, and users generally appreciate the
Upstream developers are harder to convince; they have released the software
in the form that they think is best, so it can be discouraging to see
others messing with it. Most developers suffer in stoic silence, taking
comfort in the fact that their software is finding a wider audience. But
others have taken various types of action in an attempt to influence how
distributors treat their code.
Consider some examples.
The kernel developers changed their release
process dramatically with the (successful) goal of reducing the number of
patches applied by distributors.
Some developers do their own packaging.
Jeff Waugh has suggested that
much of the packaging role of distributions could be "disintermediated"
entirely, with users routinely getting their software directly from its
Jörg Schilling inserted (widely ignored) statements into his code
stating the alteration of some parts of the program would be a copyright
Firefox makes aggressive use of its trademarks to control the changes made
Daniel Bernstein took things to a (non-free) extreme, only
allowing qmail to be distributed if it had not been modified at all; this
restriction inhibited qmail development for years until the code was
finally released into the public domain.
In the end, releasing code under a free license means giving up control
over what is done with it. So free software developers will always be at
the mercy of distributors, who will always have the right to make the
changes they think are necessary. The occasional grumble notwithstanding,
the system works pretty well; all of the parties involved share an interest
in having the software work as well as possible for their users.
to post comments)