The Debian project is known for its public brawls, but the truth of the
matter is that the Debian developers have not lived up to that reputation
in recent years. The recent outburst over the attempted "semi-hijacking"
of the dpkg maintainership shows that Debian still knows how to run a flame
war, though. It also raises some interesting issues on how packages should
be maintained, how derivative distributions work with their upstream
versions, and what moral rights, if any, a program's initial author retains
Dpkg, of course, is the low-level package management tool used by
Debian-based distributions; it is the direct counterpart to the RPM tool
used by many other systems. Like RPM, it is a crucial component in that it
determines how systems will be managed - and how much hair administrators
will lose in the process. And, like RPM, it apparently causes a certain
sort of instability in those who work with it for too long.
Ian Jackson wrote dpkg back in 1993, but, by the time a few years had passed,
Ian had moved on to other projects. In recent times, though, he
has come back to working on dpkg - but for Ubuntu, not for the Debian
project directly. One of his largest projects has been the triggers
feature, which enables one package to respond to events involving other
packages in the system. This feature, which is similar to the RPM
capability by the same name, can help the system as a whole maintain
consistency as the package mix changes; it can also speed up package
installations. Triggers have been merged into Ubuntu's dpkg and are
currently being used by that distribution.
The upstream version of dpkg shipped by Debian does not have trigger
support, though, and one might wonder why. If one listens to Ian's side of
the story, the merging of
triggers has been pointlessly (perhaps even maliciously) blocked for
several months by Guillem Jover, the current Debian dpkg maintainer. So
Ian concluded that the only way to get triggers into Debian in time for the
next release ("lenny") was to carry out a
"semi-hijack" of the dpkg package. By semi-hijack, Ian meant that he
intended to displace Guillem while leaving in place the other developers
working on dpkg, who were encouraged to "please carry on with your
existing working practices."
Ian also proceeded to upload a version of dpkg with trigger support, and
without a number of other recently-added changes. It is worth noting that
all of this work went into a separate repository branch, pending a final
resolution of the matter. So when the upload was rejected (as it was) and
Ian was deprived of his commit privileges (as he was), there was no real
mess to clean up.
Those wanting a detailed history of this conflict can find it in this posting from Anthony Towns. It is a long
story, and your editor will only be able to look at parts of it.
One of the relevant issues here is that Guillem Jover appears to be a busy
developer who has not had as much time to maintain dpkg as is really
needed. Since the beginning of the year, he has orphaned a number of other
packages (directfb and bmv, for example) in order to spend more time on
dpkg. But, as a result of time constraints, a number of dpkg patches have
languished for too long.
While this was happening, Guillem put a fair amount of the time he did have
into reformatting the dpkg code and making a number of other low-level
changes, such as replacing zero constants with NULL. Ian
disagrees strongly with the reformatting and such - unsurprisingly, the
original code was in his preferred style.
And this is where a lot of the conflict comes in, at two different levels.
Ian disagrees with the coding style changes in general, saying:
Everyone who works on free software knows that reformatting it is a
no-no. You work with the coding style that's already there.
Many developers will disagree on the value of code reformatting; some
projects (the kernel, for example) see quite a bit of it. Judicious
cleaning-up of code can help with its long-term maintainability. All will
agree, though, that reformatting can make it harder to merge large changes
which were made against the code before the reformatting was done. This
appears to be a big part of Ian's complaint: unnecessary (to him) churn in
the dpkg code base makes it hard for him to maintain his trigger patches in
a condition where they can be merged.
Code churn is a part of the problem, but Ian's merge difficulties are also
a result of doing the trigger work in the Ubuntu tree rather than in Debian
directly. Ian did try to
unify things back in August, but that was after committing Ubuntu to
the modified code. Ubuntu's dpkg is currently significantly different from
Debian's version, and, while one assumes that, sooner or later, Debian will
acquire the trigger functionality, there is no real assurance that things
will go that way. Dpkg has been forked, for now, and the prospects for a
subsequent join are uncertain.
Ian also asserts that, as the creator of dpkg, he is entitled to
special consideration when it comes to the future of that package. His
semi-hijack announcement makes that point twice. But one of the key features
of free software is this: when you release code under a free license,
you give up some control. It seems pretty clear that Ian has long since lost
control over dpkg in Debian.
So who does control this package, and how will this issue be resolved?
Certainly Ian's hijack attempt found little sympathy, even among those who
think that dpkg has not been well maintained recently. There are some who
say that the disagreement should be taken to the Debian technical committee, which
is empowered to resolve technical disputes between developers. But faith
in this committee appears to be at a low point, as can be seen in this recent proposal to change how it is selected:
It's been pretty dysfunctional since forever, there's not much
that can be done internally to improve things, and since it's
almost entirely self-appointed and has no oversight whatsoever the
only way to change things externally is constitutional change.
Meanwhile, the discussion has gone quiet, suggesting that, perhaps, it has
been moved to a private venue. The dpkg commit
log, as of this writing, shows that changes are being merged, but
triggers are not among them. It is hard to imagine that the project will
fail to find a way to get the triggers feature merged and the maintenance
issues resolved, but that does not appear to have happened yet.
to post comments)