O estado atual de desenvolvimento do RPM pode ser classificado entre “deplorável” e/ou “inimaginável”. Leiam e comentem, fresquinho do LWN.net. (em inglês, usem o google pra traduzir ou o babelfish).
RPM is an important piece of Linux infrastructure. It is the native package manager for a number of major distributions, including Red Hat’s enterprise offerings, Fedora, and SUSE. The Linux Standard Base specification requires that all compliant systems offer RPM – even those which are built around a different package management system. If RPM does not work, the system is not generally manageable. So it may be a little surprising to learn that the current status and maintainership of RPM is unclear at best.
Once upon a time, RPM was the “Red Hat Package Manager.” In a bid to establish RPM as a wider standard – and, perhaps, to get some development help – Red Hat tried to turn RPM into a community project – rebranding it as the “RPM Package Manger” in the process. But core RPM development remained at Red Hat, under the care of an employee named Jeff Johnson. That, it would seem, is where the trouble starts.
Back in early 2004, an RPM bug report was filed. The reporting user had made a little mistake, in that he had tried to install a package on a system where /usr was mounted read-only. Needless to say, this operation did not work as intended – an outcome which the bug reporter could live with. This person, however, did think that it might have been better if RPM had not corrupted its internal database in the process of failing. He suggested that RPM should keep its internal records in order, even if the system administrator has requested something which cannot be done.
The ensuing conversation – lasting for over two years – deserves to become a textbook example in how not to respond to bug reports. Mr. Johnson took the position that, since RPM was being asked to do something erroneous, its subsequent mangling of the package database was not a bug. Instead, it seems, this behavior should be seen as an appropriate consequence for having done something stupid. Mr. Johnson repeatedly closed the bug, stating his refusal to fix it. Numerous other participants in the discussion made it clear that they disagreed with this “resolution” of the bug, but nothing, it seemed, could convince the RPM maintainer to put in a fix.
In February, 2006 – almost two years after the bug report had been entered – Mr. Johnson posted a one-line comment to the effect that read-only mounts were properly detected in RPM-4.4.5. This might seem like the end of the story, except for one little problem: Fedora currently ships version 4.4.2, and even the Fedora development repository has not gone beyond that. SUSE remains at 4.4.2, and the current RHEL offerings have rather older versions. Mr. Johnson has continued to make RPM releases, but the distributors are not picking them up. They are, instead, shipping an older version of this crucial tool, augmented with a rather hefty list of patches.
Part of what is happening here is that Mr. Johnson is no longer a Red Hat employee, having been encouraged to pursue other opportunities. He does, however, continue to show up on the Red Hat bug tracker when RPM issues are being discussed; as a current example shows, he does not appear to have adopted a friendlier attitude toward RPM users (or his former employer) over time. There has been talk on the mailing lists about removing his access to the bugzilla database – an action which may have occurred by now.
Red Hat’s Greg DeKoenigsberg, who has responsibility for the company’s relations with the development community has stood up and pointed out, however, that simply silencing one difficult personality will not address the real problem:
When we fired jbj, we didn’t have the courage to draw a line in the sand and say “we’re taking upstream ownership of RPM back.” Why not? Because we thought it would be difficult politically? Because we didn’t want the responsibility anymore? Because nobody in management actually cared enough to think about the ramifications? I don’t know.
Fast forward a year plus, and here we are. We’re in a position where we have, essentially, forked RPM — and no one is willing to admit it. No one is willing to take ownership of what we’ve done.
Perhaps jbj “owns” RPM, in its current incarnation, by default, because no one else is willing to touch it. That’s fine. He can have it. But that is not what *we* are using.
So, when Jeff Johnson walked out the door at Red Hat, he took RPM with him. Since then, few distributors have wanted to use his releases, but no other organized project around RPM has come into existence. For the purposes of the people using distributions from Red Hat and SUSE, RPM is essentially unmaintained.
There has been no clear message to users about the state of RPM. Some Fedora users have asked, via yet another bugzilla entry, for an update to Jeff Johnson’s current release, but nobody has posted a definitive reason as to why that will not happen. But it does appear that there is no interest within Fedora to depend on Mr. Johnson for anything, much less an important piece of infrastructure, so Fedora appears unlikely to move to the newer releases.
What Greg DeKoenigsberg has said – backed up by Michael Tiemann – is that the time has come for Fedora and Red Hat to own up to what has happened and formalize the new status of RPM. The current situation, where RPM has been forked but nobody is saying so, will not lead to anything good in the long run. The new RPM – perhaps the “Red Hat Package Manager” yet again – needs to have its existence acknowledged and its maintainership made clear. Either that, or Red Hat and Fedora should acknowledge the current RPM maintainer and move toward rejoining with his version of the code. Until one of those things happen, there will continue to be a dark cloud of uncertainty surrounding a tool which is heavily depended upon by vast numbers of Linux users.
(See also: the the Fedora rpm-devel wiki page, which lists features found in the current RPM release but not in Fedora’s version).
Ts ts ts… e viva o .deb (apt-get) 🙂