.deb and .rpm package coexistance
Grettings fellow Debian developers and debian-devel readers!
A friend and I got into talking about dpkg and rpm. Basically, we
both agree that Debian rules on core packages and such. For the both of
us, we would use Debian 2.x or whatever as the base system. But, the fact
remains that a lot ofppackages are in rpm format, and Matt tends to like
RH mainly because there are a lot of 3rd party packages in said format,
plus a few other reasons (see web url at bottom), and in order to rpm a
package on a debian system, you have to rpm -i --nodeps, which can be
messy, and it's probably not too good in practice. So we kinda got to
thinking - what could be done about this?
Well, we came up with a few ideas.
First, Matt said maybe fake (rpm?) packages for libc6 and a few basics
that almost all programs require. Pro: fairly simple. Con: Specific
operation - IMHO, a solution should be automatic to a debian system ; and
this wouldn't satisfy all programs/dependancies. It's too specific, IMO.
Second, I thought about creating an rpm database on the debian box. This
would require dpkg to also create/modify an rpm database when it installs
a debian package. This would require a modification of apt/dpkg, and in
addition, the package names aren't always the same. Perhaps the dpkg
format could say which rpm packages it provides. Again, just an idea.
But then, in addition, there packages on debian/rpm that dont have the
same files. (just for an example for debian 2.0, dpkg xbase and rpm X
files (I know it's no longer valid arg here, but just to illustrate)).
Another con that came up later...
"Installing an X rpm may only do 1 part of what a debian package does. If
you assume that the full debian package is installed, you run the risk of
allowing a dependancy that really isn't there, as some of the files
assumed in the debian package aren't really there, becuase really only
half of what's in the .deb package has been installed by rpm"
On this note, the rpm binary (usr/bin/rpm or whatever) wouldn't be called
by the user... only dpkg would be called, perhaps dpkg would call rpm in
turn. An example might be 'dpkg -i --rpm bleh.rpm', although I think rpm
could still be called to install a package, but then the debian database
might not be updated. The basis behind this, I guess, is that dpkg would
maintain 2 databases - one dpkg, and the other rpm. Of -course-, take
note here, this option (and just about anything regarding the use of rpm's
in dpkg ) should have the option to be disabled. Say, /etc/dpkg.conf or
whatever has a 'KEEP_RPM_DB=Yes' option in it, or somesuch. And maybe a
utility to sync the two databases?
I really like this idea, personally.
Then, Matt came up with what I shall dub the 'abstract' idea for now. (I
think someones gonna kill me for this). Basically, instead of a package
having a dependancy to another specific package, it would havean abstract
depend. For example, mutt or pine wouldn't depend on sendmail, or deliver
or whatever specifically. Instead, it would be linked against
'mail-transport-agent', as is currently implemented in some way already in
Debian, as Matt pointed out to me -- but it's a possibility to be taken
further.) Most programs would be dependant on 'libc6-capable' or
somesuch. Major problems I(we) see with this: 1) RedHat would have to
join in such an effort to make it so that rpm's could easily be installed
on a Debian system. 2) IMHO, I dont think all dependancies could be
resolved using an abstract name. I just have this feeling that it's not
specific enough, and that it cant be applied to all packages.
A major plus: All (well, most) disto's could be compatible with each
other, and to debian. Think: Debian, RH, Bero, Stampede, SuSE, and the
list goes on. As matt later put it,
>From the MUSH:
Matt says, "Compatiblity with the other distros wouldn't exactly
happen merely because they use rpms.."
Martin hmms. "well, how did you mean compatibility would come,
then?
Matt says, "They'd have to upgrade their distros to the version of
rpm that supports the new features, and of course add the
abstract provisions/dependancies."
Matt says, "Well, I meant that once the functionality was in the
rpm program, other distros could adopt it."
You say, "oh, okie."
Matt says, "But, we're still thinking in a one-directional sense,
rpm to debian."
Matt says, "Which works, since debian is the more restrictive
system."
But still, it opens the possibility.
[At this point, with Matt's concern, I would like to point out that you
should take Matt's last comment on 'restrictive' with a grain of salt.
It's more that Debian is very good at sticking with one standard/rule, and
enforcing it, and making sure all bugs are fixed and everything is stable
- Restrictive might not be the right term, but it's a good meaning here]
Another odd idea I had in mind, was kind of like the second, only maybe
there would be a database on the internet with package dependancy
translations. Rpm dependancy needs debian package(s) x y and z, etc.
This would require sponsering of a server tho, and an internet connection.
Perhaps the interchange db could be put onto a cd...?
These are a few ideas we had. Basically, our goal, or train of thought,
was of getting the best parts of several distro's packaging systems and
putting them into one(system). (We think of using debian as the main base
system for it's strengths, and rpm pakcages for things like gnome, X, etc.
-- Basically, you can use whichever suits your needs or preferences.)
Neither packaging system would die, maybe a few modifications, and,
optimally, as I see it, only a modification in how the programs work, and
not how they're packaged (or minimal changes to a few packages)
So, those are our ideas. I've recorded (some of) our conversation on the
MUSH and have made them available at http://ucs.orst.edu/~heldm/conv . I
hope to hear back from a bunch of you on this... I think this is something
that could -really- set debian ahead of the pack, and keep it's high
integrity for quality (minus my grammar :). Also, It's also possible that
this has been discussed before, dont kill me if it has :>. Hopefully,
this will spur some debate and/or ideas in this general area.
Thanks!
Do Svidonia,
Martin Held
heldm@ucs.orst.edu
-------------------
The way to love anything is to realize that it might be lost.
Reply to: