RPM: Plans, goals, etc.
Saturday, December 16, 2006
Everybody knows it, RPM needs a serious overhaul... so why isn't anything being done? Well, turns out, Fedora has stepped up to the plate:
Read more @ fedora-announce-list redhat.com and at All About Linux. Digg this story.
There has been a lot of discussion in the past few months about RPM -- its present state, its future plans, and its leadership team. In particular, the Fedora Project has received numerous requests asking us, "what are you guys doing about RPM?"What is being done?
Here is our answer, in a few words. Then if you want more, you can read the rest of this note:
The Fedora Project is leading the creation of a new community around RPM. One in which the leaders can come from Fedora, from Red Hat, from Novell, from Mandriva, or from anywhere. Job #1 is to take the current RPM codebase and clean it up, and in doing so work with all the other people and groups who rely on RPM to build a first-rate upstream project.
What we're doing here is collecting together everyone who has a stake in the future of RPM and building a healthy community around it. This involves major bug fixing, development work, performance work and making regular, predictable releases. As it stands today, we don't have these things. This is a good first step. Could you call it a fork? Maybe. But we're doing it because we think it's the right thing to do, for distributions all the way down to the individual users of RPM.Here are some initial goals of the project:
- Give RPM a full technical review, based off of RPM 4.4.2. This is the common base for Novell and Red Hat. Look what vendors have on top of 4.4.2 and work towards a shared base. Figure out which pieces or code paths are unnecessary, poorly implemented, or receive little to no use, and either clean them up or clear them out. Make RPM simpler.
- There's a lot of folks out there who are using RPM, including the various Red Hat/Fedora based distros, Suse, and Mandriva, just to name a few. Simplificaion and focus on the parts of RPM that are core to these stakeholders is a good way to start.
- Do a better job with bug fixes. Squashing bugs that already exist, or closing out bugs that are related to parts of RPM that are superfluous.
- Give RPM the stability that it needs to continue to be the cornerstone of many distributions.
- Enhance the rpm-python bindings, which includes understanding and gathering together the work that already exists in this area.
Read more @ fedora-announce-list redhat.com and at All About Linux. Digg this story.