User: Password:
Subscribe / Log in / New account

RPM -- plans, goals, etc.

From:  Max Spevack <>
Subject:  RPM -- plans, goals, etc.
Date:  Thu, 14 Dec 2006 12:42:03 -0500 (EST)

Hash: SHA1

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?"

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.


The Fedora Board has spoken with Fedora stakeholders both inside and 
outside Red Hat, developers/maintainers in Novell, and other parties who 
rely on RPM as the foundation for their distributions.  We wanted to make 
sure those parties agreed that this was the right thing to do for their 
respective communities. We touched base with some of these people at the 
recent LSB conference, and the overwhelming community opinion there was in 
favor of what we are outlining here.

At the most fundamental level, we begin with two points:

(1) RPM is an important piece of technology, not just for Fedora or for 
Red Hat, but for many other distributions and users. Its stability and 
maintenance are critical.

(2) Red Hat realizes the need to build a strong community of contributors 
around RPM, that the upstream of RPM needs to be handled in a manner which 
allows contributors and developers to have maximum freedom in their 
modifications, and that those modifications can be easily shared across 

Expanding on that:

(3) RPM, as a file format, is good at what it does and capable of being 
the core of a Linux distribution.  From the Fedora perspective, we are not 
particularly interested in making any grand deviations from it at this 

(4) RPM, as an application, has a fairly mature feature set that we are 
very interested in stabilizing and bug fixing. Furthermore, we want to 
make sure that RPM is a stable and simplified base for the building of 
other technologies on top of it.  Down the road, we might be interested in 
exploring a variety of new features, but we don't believe that should be 
the initial focus of our efforts.

Ultimately, the Fedora Project and Red Hat are committed to seeing RPM be 
as healthy and vibrant as many other large open source projects -- GNOME, 
Xorg, etc -- consumed and contributed to by many companies, users, 
distributions, and developers. Our overall goal for RPM is to ensure that 
is has consistency, reliability, and stability.

We switch now to a handy Q&A format:

Q -- So what, specifically, are you doing with RPM?  And where is the work 
going to happen?

We have set up a new repository, wiki, and webspace -- external to any 
distribution or company -- for RPM, to which anyone can contribute. A 
reboot of the upstream, if you will.  We don't expect that everyone will 
be running the same version of RPM, or run with the same patches, but we'd 
like for there to be a single place that everyone can refer to as 
upstream, and be able to contribute patches.

There is already a contributor base that exists around RPM -- engineers 
within Red Hat, Novell, Mandriva, and other organizations. We don't want 
to leave those people behind -- we want to do a better job of 
collaborating and accepting their work.

Everything will live at, with a relaunched wiki, code repository, 
and mailing lists.  As for itself, its hosting and maintainership 
is outside of Red Hat, and is being generously provided by Duke 

Q -- How is that different from what currently exists?

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.

Q -- Where is all this stuff going to happen?  What's the public mailing 
list and wiki?  What *EXACTLY* is Fedora or Red Hat going to do?

Short answer --

Over the past few years, engineers from Red Hat and other companies, as 
well as a community of independent contributors, have been working on and 
maintaining their own versions of RPM -- sometimes sharing patches, 
sometimes not.  It is important that these contributions move through an 
upstream process like many other projects do, in order to maintain a 
healthy community and proper checks and balances.

To that end, Red Hat is adding an additional engineer that works full time 
on upstream issues including patch reviews, community development, etc. 
Additionally other Red Hat engineers will contribute to RPM like any other 
open source project -- working on the release-engineering parts of RPM 
such as rpmbuild, and doing maintenance work.

Additionally, here are some of our initial goals:

* 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.

* In turn, this gives us a chance to 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.

Most importantly, this work will be done in the community, fully 
transparent with the help of the community and RPM stakeholders outside of 
Red Hat or Fedora.  This is all about incremental steps, not blowing 
everything away and starting from scratch.

Q -- When is all of this happening?

Starting now.  Planning and review happening over the next 3-6 months, at  Implementation happening appropriately alongside that planning, 
as in most any free software project. Initially, Paul Nasrat is the 
primary developer/maintainer dedicated to RPM from Red Hat.  At the same 
time, we want to make sure that leadership has a chance to develop and 
emerge, rather than be mandated.

Q -- How did we end up here?

This is the part of the email in which Red Hat takes some accountability 
for the current situation:

* Several years ago, the maintainer of RPM worked for Red Hat. When he 
left, he continued his own work on RPM, which he acknowledges is a fork. 
And that's fine -- we support anyone's right to fork, since forking is one 
of the paths to innovation in open source software.

* Red Hat didn't commit the necessary resources to RPM following that 

* RPM, without a strong upstream, has languished as a result.

* The community has (rightfully) been demanding that the situation be 
fixed, and this is the first step in that effort.

- -- 
Max Spevack
+ gpg key --
+ fingerprint -- CD52 5E72 369B B00D 9E9A 773E 2FDB CB46 5A17 CF21

Version: GnuPG v1.4.6 (GNU/Linux)


fedora-announce-list mailing list

(Log in to post comments)

RPM -- plans, goals, etc.

Posted Dec 14, 2006 18:14 UTC (Thu) by rvfh (subscriber, #31018) [Link]

You sure are expecting the question, but... what about switching to apt for the application (NOT the packages)?

I seem to remember an apt-rpm application that Conectiva before being bought by Mandrake (at the time) was using, as well as synaptic as a GUI package management tool.

I even had heard that Mandriva was thinking of switching to apt at some point...

RPM -- plans, goals, etc.

Posted Dec 14, 2006 19:13 UTC (Thu) by proski (subscriber, #104) [Link]

apt-rpm still needs rpm application.

RPM -- plans, goals, etc.

Posted Dec 14, 2006 20:05 UTC (Thu) by smoogen (subscriber, #97) [Link]

This is one of those frequently asked questions I see on various IRC, webforums, and mailling lists

apt is to yum
deb is to rpm

apt has its advantages over yum and vice versa.. the main differences I see are world view. [What I mean is that if you were to type ls and instead get the output you get from DOS dir, you would be perplexed and annoyed.]

I remember a similar comparison over deb and rpm in the past where each had its technical merits that the other didnt.

Personally I think they should all swith to conary :P

RPM -- plans, goals, etc.

Posted Dec 14, 2006 22:36 UTC (Thu) by JoeBuck (guest, #2330) [Link]

Correct: .deb/dpkg is to rpm as apt is to yum. However, the RPM world is missing a key concept from the dpkg world, and its lack means that corrupted RPM databases are far more common than corrupt dpkg databases.

A Debian package can be half-installed or half-removed, and this state is kept track of. This means that, on a subsequent run, the half-completed action can be resumed and completed. With rpm, on the other hand, this concept doesn't exist, so if rpm locks up or a crash or power fail happens during an rpm operation, you wind up with a corrupt database. The RPM folks tried to deal with that by making rpm unkillable except with kill -9, but then users are forced to use kill -9 to unwedge the thing. The result, frequently, is a big mess. But you don't corrupt the world by killing apt-get on a Debian or Debian-like system (you do if you're running apt-on-top-of-RPM on an RPM system).

Adding the missing states is possible but tricky.

RPM -- plans, goals, etc.

Posted Dec 15, 2006 0:30 UTC (Fri) by drag (subscriber, #31333) [Link]

One of the things that I thought was bizzare was how I can have multiple versions of the same package installed.

I don't know how to fix it (aside from having to manually display and walking through it in a tedious way with rpm uninstalling and reinstalling stuff) and I don't know how it's happenned, but it does.

RPM -- plans, goals, etc.

Posted Dec 15, 2006 1:25 UTC (Fri) by mattdm (subscriber, #18) [Link]

This is actually a useful feature, particularly for packages like the kernel, where you really might want to have multiple versions around. And, it's used on x86_64 to provide 32-bit and 64-bit versions of the same libraries.

RPM -- plans, goals, etc.

Posted Dec 15, 2006 9:22 UTC (Fri) by k8to (subscriber, #15413) [Link]

You say feature, I say bug. The problem is that rpm can end up with multiple versions of the same package installed whether or not this makes any sense. In the debian world you have to explicitly allow the possibility for various versions of the same tool to be installed, where it makes sense.

This trades for a different problem where you want to (as a special case) install two versions of something that only makes sense in your circumstance. In RPM you might be able to do this and not break things, or things might break. In deb-world, the system just refuses.

I prefer the packaging system that refuses to do nonsense actions, over the one that lets me take nonsense actions that might happen to make sense sometimes.

RPM -- plans, goals, etc.

Posted Dec 15, 2006 12:29 UTC (Fri) by mattdm (subscriber, #18) [Link]

I'm not sure your preference is really helpful. Any powerful system will let you do some things which are nonsense. The bug here is that if RPM dies in the middle of an upgrade transaction (power loss, or hardware error, or software bug), you'll end up with some of the new packages installed but the old ones not yet removed. This boils down to the earlier issue of partially-installed packages -- there's not really a problem with allowing duplicate packages per se.

RPM -- plans, goals, etc.

Posted Dec 15, 2006 13:07 UTC (Fri) by drag (subscriber, #31333) [Link]

Ya but how can it work out that i have two versions of a libsdl lib installed?

How does RPM deal with that conflict? Were in the filesystem are these two things support so coexist.

It's all confusing and mysterious to me.

The only other thing that bugs me is the unbearable slowness of Yum. I know it's python and all, but I also use GUI python apps that feel nearly as fast as anything else.

This lead me to the original problem I had. I have a older machine that I use CentOS on as a desktop at work. It's very old, probably 300 mhz or whatnot.

Normally the speed is irritating, but it's mostly a glorified terminal so it's not a big deal.

But there was a bunch of updates flashing on that little red button and I decided I needed to update it.

I thought I gave myself enough time, but I underestimated the unbareable slowness of the beast and after a while I just plain ran out of time and had to cancel the upgrade.

A week later I was able to get back to it and lo it took me freaking 3-4 hours to resolve the issue. I work evenings and I didn't get finished with the stupid thing until like 4 or 5 AM in the morning.


(otherwise I like CentOS)

Maybe you (or someone, maybe I'll look at but I can't make any promises, it'll take me a few months to figure out this stuff as I am no programmer) need to rewrite the math-intensive portions or something in C or Pyrex and import it back into the program as a module. I expect that there is only certain functions that take up 90% of the time..

RPM -- plans, goals, etc.

Posted Dec 15, 2006 13:29 UTC (Fri) by rvfh (subscriber, #31018) [Link]

What bothered me most when I had to use CentOS 3 was that yum install would always grab the latest info from the servers (which took for ever).

For deb users, it's as if apt-get install was always running apt-get update beforehand.

RPM -- plans, goals, etc.

Posted Dec 15, 2006 14:47 UTC (Fri) by smoogen (subscriber, #97) [Link]

Interesting. This must be a configuration option then as most of the Debian systems I have helped maintain had to have a 'apt-get update' run before I could get useful information. I wasn't the primary admin so this could have been something the other admins did for some obscure reason.

RPM -- plans, goals, etc.

Posted Dec 15, 2006 17:57 UTC (Fri) by Zenith (subscriber, #24899) [Link]

> had to have a 'apt-get update' run before I could get useful information

What he meant was that what rpm does is LIKE apt doing an 'apt-get update' first every time you used apt. It does of course no this, as it is, well, annoying :)

RPM -- plans, goals, etc.

Posted Dec 15, 2006 20:27 UTC (Fri) by drag (subscriber, #31333) [Link]

The first thing about yum that I learned was the '-C' (or is it -c?) option which runs it using cached information so it doesn't pull down new headers each time.

RPM -- plans, goals, etc.

Posted Dec 15, 2006 21:02 UTC (Fri) by Zenith (subscriber, #24899) [Link]

Neat, I did not know about that little trick, which probably comes from the fact that I have spent way too little time administrating a Fedora/Red Hat system :)

But thanks for the tip anyway.

RPM -- plans, goals, etc.

Posted Dec 15, 2006 15:07 UTC (Fri) by smoogen (subscriber, #97) [Link]

In the case of multilib packages, it works it out because one is an .i386 or .i686 and one is a x86_64. It then upgrades the right one. To see what the packages are in each listing you can do a 'rpm -ql <package name>'.

The unbearable slowness of yum is not something I can help with. Especially the older yum that is on the Centos-3.8 boxes.. the difference in speed with python gui and python yum is one is dealing with a database and the other is moving pixels.

RPM -- plans, goals, etc.

Posted Dec 15, 2006 20:41 UTC (Fri) by drag (subscriber, #31333) [Link]

Well that's what I was saying about pyrex.

Python is one of those things that kicks-ass and is plenty fast, but you have to know it's limitations.

One of those is dealing with a lot of math and such. Lots of intense calculations is not good for it.

So the basic idea of it is:
A. that you write the entire program in python.
B. Run it, benchmark it, profile it, optimize it as much as you can in pure python.
C. Once you are sure that you have it as fast as it can go and if it's still slow then you find out which parts are the most intense and rewrite them in C as modules.
D. make sure everything is fine.

It's just what you do. This is why it's possible to use python for things like programming game logic and physics. It's used by all sorts of stuff like that.

Rewriting stuff in C is a huge pain in the ass though. So they invented Pyrex. Pyrex is something were you have a python-like syntax, but you can do C-like syntax also and it's something you have to compile. It's specificly designed to create python modules.

Doing straight compile from python-like code doesn't offer much of a performance enhancement, but with proper optimizations and such you can actually get within the realm of pure C program.

There have been cases were pyrex is faster then C because you don't need a lot of the boiler-plate code and it's cleaner and more easier for the programmer to understand.

Of course you would like to avoid using Pyrex and such and do as much as you can in Python before you give up on it, otherwise with inapropriate use of pyrex can defeat much of the benifits of using python.

RPM -- plans, goals, etc.

Posted Dec 16, 2006 23:14 UTC (Sat) by seyman (subscriber, #1172) [Link]

> In the debian world you have to explicitly allow the possibility for
> various versions of the same tool to be installed, where it makes sense.

In the debian world, the package naming conventions demand you add the most significent version number to certain package names.
This is a hack in order to work around said feature so I'ld be wary of changing rpm's behaviour to match dpkg's

RPM -- plans, goals, etc.

Posted Dec 15, 2006 1:28 UTC (Fri) by bokeoa (guest, #32455) [Link]

Try finding out which architecture each one is with the following command:

rpm -q --qf '%{name}-%{version}-%{release} %{arch}\n' package_name

And to remove one of the packages, do the following:

rpm -e package_name.arch

Hope that helps!

Read-only Wiki?

Posted Dec 14, 2006 18:41 UTC (Thu) by wcooley (guest, #1233) [Link]

What good is a wiki that's read-only? I went to the new site hoping to contribute some of the docs I've written but I can't even create a personal page. You can use wiki software as a content manager, but it's not really a wiki if it's not a collaboration tool.

Read-only Wiki?

Posted Dec 14, 2006 18:42 UTC (Thu) by skvidal (guest, #3094) [Link]

Make an account and then you can be added to edit the pages. Otherwise all wikis just turn into a giant pr0n advertisement. Or herbal viagra.

if you'd like to help out on docs that'd be great.


Read-only Wiki?

Posted Dec 14, 2006 19:25 UTC (Thu) by wcooley (guest, #1233) [Link]

Creating an account was the first thing I did. A little more openness of access (even if it means stronger registration validation) would remove the necessity to beg for access, which is usually past my Bothering Point. (Which is part of the reason I have my own wiki in the first place.)

I'm not volunteering to write documentation as such, but I am willing to share the bits and pieces I've written over the years (which, admittedly, isn't much).

Also, a comprehensive update of packager-oriented documentation seems to be the most salient item missing from the list above. My biggest frustrations through the years with RPM haven't been with technical errors but the paucity of specfile documentation, including not only reference-level material but also "best practices" guidelines and such.

Read-only Wiki?

Posted Dec 14, 2006 19:38 UTC (Thu) by jkeatingatredhat (guest, #40062) [Link]

That is indeed something that has been missing. Fedora has created some documentation around this and best practices through our packaging guidelines. What I hope is that overtime each vendor of RPM will link their specific documentatino from the website. I know Red Hat has some resources that were waiting for this upstream reboot in order to start contributing / cleaning up some documentation so hopefully that will happen soon.

As for getting write access, I tweaked the Contribute page slightly so that there is a link from 'request' EditGroup to the Communicate page which lists various avenues to communicate with folks who can add you to EditGroup. Thils little dance is unfortunately a bit necessary for popular wikis to prevent spam.

Read-only Wiki?

Posted Dec 14, 2006 19:45 UTC (Thu) by bronson (subscriber, #4806) [Link]

Not true. Mediawiki offers very good anti-spam tools, and I'm sure other wikis do as well. So far, it's been very easy to keep free of spam -- maybe one easily-reverted attack per week. Just throw an RSS feed of every edit in your feed reader and quickly scan through it occasionally.

For some reason, openzaurus spammers have only wanted to deface the Main Page's Discussion page.

RPM -- plans, goals, etc.

Posted Dec 14, 2006 19:51 UTC (Thu) by madscientist (subscriber, #16861) [Link]

I hope the folks working on this keep the LSB in mind. LSB mandates an earlier version of RPM file format and it would be nice if the newer tools provided easy ways to create/verify/etc. LSB-standard RPM files.

RPM -- plans, goals, etc.

Posted Dec 14, 2006 20:16 UTC (Thu) by skvidal (guest, #3094) [Link]

The lsb/fsg meeting last week in berlin where we had a face-to-face packaging meeting was where some of this was discussed. So, yes, the lsb has been consulted and considered in this decision.

Jeff Licquia and Ian Murdock both had some very hopeful things to say.



Posted Dec 15, 2006 6:48 UTC (Fri) by eklitzke (subscriber, #36426) [Link]

I'm really excited to see that there will be renewed interest in the python bindings for rpm. I recently had to use them, and the documentation for them was almost nonexistent. Questions about them on mailing lists and such generally pointed to the two (IIRC) very short and not-too-helpful guides for using them that are floating around online.

From doing this research into the RPM bindings and how to work with RPM, I got the impression that a lot of really messy RPM internals were needlessly exposed -- probably because the bindings were written for yum, which is done entirely in python. Cleaning up the Python bindings and providing better documentation would make it really easy to do cool/useful things with RPM (e.g. writing custom in-house applications for managing and deploying packages).


Posted Dec 15, 2006 13:24 UTC (Fri) by skvidal (guest, #3094) [Link]

The bindings were not written for yum. They existed long before yum came along.



Posted Dec 15, 2006 15:42 UTC (Fri) by Richard_J_Neill (subscriber, #23093) [Link]

There's a great deal to like about Mandriva's URPM suite:
urpmi - install packages and deps [also allows tab-completion on pkgname]
urpme - remove
urpmq - query
urpmf - what package do I need to install to get file /usr/lib/foo ?

It's very similar to apt in what it does.


Posted Dec 22, 2006 20:32 UTC (Fri) by cdmiller (subscriber, #2813) [Link]

I second this, Mandriva's URPM is very nice. I have had less trouble with URPM than yum or apt.

RPM -- plans, goals, etc.

Posted Dec 15, 2006 22:37 UTC (Fri) by GMCL2 (guest, #42253) [Link]

Hello everybody,

I've used during several years rpm and deb technology, I've several real
questions :
- Why recommended and suggested packages doesn't exists into rpm ?

- Why the performances are bad with rpm compar to deb ?

- I haven't seen a same mechanism of dpkg-reconfigure ( ) into rpm system, it's
really a gain of time to configure a new software quickly.

- Why the dependencies packages are on files, not on packages, same as
deb ?

- Possible to compile some part of the system WITH automatically
recompilation during the upgrade (possible with apt-build )

Moreover, some features aren't present into deb and rpm :
- to have the same software with different versions (possible with

- install easily a software same as that on windows ( or or Mac-Os

It's maybe the time to refactor all good ideas around software management
into the same product ?

RPM -- plans, goals, etc.

Posted Dec 16, 2006 22:57 UTC (Sat) by seyman (subscriber, #1172) [Link]

> - Why recommended and suggested packages doesn't exists into rpm ?

It was included recently in JBJ's fork.
Maybe it will find its way upstream soon.

> - Why the performances are bad with rpm compar to deb ?

I've never actually seen this.
Can you point us to a benchmark or something ?

> - Why the dependencies packages are on files, not on packages, same as deb ?

Because the packages depend on files, not on other packages.
Dpkg is doing it wrong, in this case.

> - to have the same software with different versions (possible with gentoo)

Provided there are no file conflicts, rpm should allow you to install any number of versions of a given software.
This has been possible for quite some time.

RPM -- plans, goals, etc.

Posted Dec 18, 2006 22:05 UTC (Mon) by cortana (subscriber, #24596) [Link]

> > - Why the dependencies packages are on files, not on packages, same as deb ?

> Because the packages depend on files, not on other packages. Dpkg is doing it wrong, in this case.

At the risk of starting a huge OT discussion... why?

Say you have the package 'foo' that contains an executable that links against How does 'foo depends on /usr/lib/' express the fact that foo uses symbols that were introduced into in version 4.2? I may only have libbar version 4.1 installed, and so even though the dependency is satisfied I am unable to run foo.

RPM -- plans, goals, etc.

Posted Dec 19, 2006 11:52 UTC (Tue) by seyman (subscriber, #1172) [Link]

> At the risk of starting a huge OT discussion... why?

Because the dependencies for a package can be in any number of packages, all of which would resolve them.
If I need the mysql client libs, it doesn't matter whether the package is called mysql-client or MySQL-client or anything else. It just matters that the library that I'm linking against is installed on my system.

> How does 'foo depends on /usr/lib/' express the fact that foo uses symbols that were introduced into in version 4.2?

Package dependencies should be used for symbol versioning but these should compliment file dependencies, not replace them (IMHO, of course).

RPM -- plans, goals, etc.

Posted Dec 21, 2006 13:42 UTC (Thu) by cortana (subscriber, #24596) [Link]

This only seems to be an issue because of the lack of a standardised method for determining the proper dependencies that a package should end up with. In Debian, if I was packaging a program that links against, during the package build process I would use the dpkg-shlibdeps program which basically does this:

cat /var/lib/dpkg/info/*.shlibs | awk '$1 == "libmysqlclient" && $2 == "15" {print $3, $4, $5, $6, $7, $8, $9}'. (Does anyone know a better way to tell awk to 'print the rest of the line', BTW?)

The output is libmysqlclient15off (>= 5.0.24-2), which I would use directly in the package's Depends field.

Here's a more typical example:

$ dpkg-shlibdeps -O /usr/bin/mysql
shlibs:Depends=libc6 (>= 2.3.6-6), libgcc1 (>= 1:4.1.1-12), libmysqlclient15off (>= 5.0.24-2), libncurses5 (>= 5.4-5), libreadline5 (>= 5.2), libstdc++6 (>= 4.1.1-12), zlib1g (>= 1:1.2.1)

RPM -- plans, goals, etc.

Posted Dec 21, 2006 13:49 UTC (Thu) by Randakar (guest, #27808) [Link]

> Because the dependencies for a package can be in any number of packages,
> all of which would resolve them.

That's bogus. It's easily possible for different packages to provide the same file with -different- contents. deb packages simply say 'Provides: foo' in their package headers if they want to give users a choice of packages.

File dependencies however plainly don't cover a number of cases, like kernel versions with or without certain features, udev revisions (which can 'add files' in /dev without actually packaging them), certain types of library conflicts..

Personally I think all those RPM people just have no idea what they're missing out on with .deb.

Worse, instead of just saying 'argh, this project was abandoned, but hey look, we have a great alternative with DPKG' they embark on something that can only lead to massive duplication of effort.

RPM -- plans, goals, etc.

Posted Dec 16, 2006 13:30 UTC (Sat) by arekm (subscriber, #4846) [Link]

,,Job #1 is to take the current RPM codebase and clean it up'' - this needs clarification, takes old codebase (4.4.2) that is commonly used NOT current rpm codebase (4.4.7).

Primary codebase can be found on, mailing list on:

Basicaly we have now 2 forks of rpm: JBJ (rpm author) on wraptastic and fedora people (well, real participant list seems to be a secret) on

RPM -- plans, goals, etc.

Posted Dec 16, 2006 17:26 UTC (Sat) by smoogen (subscriber, #97) [Link]

Actually you have 4 or more forks:

Red Hat/Fedora RPM
Wraptastic (JBJ)
(even Turbolinux has(had?) patches that do things )

Hopefully they will get it down to 2 forks :).

RPM -- plans, goals, etc.

Posted Dec 16, 2006 22:39 UTC (Sat) by arekm (subscriber, #4846) [Link]

Using this logic we have the same number of rpm forks as number of linux ditributions that have rpm. Each linux distro has own patches for rpm :)

Embarrassing RPM bug

Posted Dec 18, 2006 22:07 UTC (Mon) by cortana (subscriber, #24596) [Link]

Is the <a href="">embarrassing RPM bug</a> slated to be fixed (rather than crudely worked around)? :)

Copyright © 2006, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds