Who maintains dpkg?

Please consider subscribing to LWN Subscriptions are the lifeblood of LWN.net. If you appreciate this content and would like to see more of it, your subscription will help to ensure that LWN continues to thrive. Please visit this page to join up and keep LWN on the net.

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 years later.

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.

