LWN.net Logo

deb vs. rpm vs. gem

deb vs. rpm vs. gem

Posted Mar 10, 2004 8:45 UTC (Wed) by stuart (subscriber, #623)
In reply to: Rock Linux 2.0 released by jamesh
Parent article: Rock Linux 2.0 released

Yes I do find your post a bit offensive. There are good technical reasons to use deb instead of rpm, at least historically. Maybe rpm is now closer to not going titsup.com regularly.

Choice is a good thing thought....right?


(Log in to post comments)

deb vs. rpm vs. gem

Posted Mar 10, 2004 10:35 UTC (Wed) by jamesh (guest, #1159) [Link]

I wasn't focusing on technical aspects of the different packaging formats. Instead, whether there are incompatible package collections available or not.

If you find a .deb on the internet, it will almost definitely work with Debian (of some version). The dependencies will point at package names that exist in Debian (rather than some other .deb based distro that has chosen a different set of package names).

If you find a .gem package on the internet now, it is almost definitely for Rock Linux.

The same is not true for RPM packages due to the number of RPM based distributions.

So having a different packaging format does have its advantages. At the same time, the fragmentation is a disadvantage. I suppose that if you are developing a new distribution, you would need to weigh up the pros and cons.

deb vs. rpm vs. gem

Posted Mar 10, 2004 12:21 UTC (Wed) by ikm (subscriber, #493) [Link]

Naming conventions and packaging format are different things. One could use rpm, but add a postfix to differentiate from other distributions, e.g. something like "mc-4.5.55-mandrake.rpm" versus "mc-4.5.55-rocklinux.rpm". No one seems to do such sort of things though.

deb vs. rpm vs. gem

Posted Mar 10, 2004 12:58 UTC (Wed) by crankysysadmin (guest, #19449) [Link]

I don't think the postfix prevents problems. I have many times gotten RPMs from rpmfind.com that had postfixes for the distro, and they worked (by sheer luck -- this was way before I had any package mgmt clue). Then later I found similar packages I expected to work which required that I change out binx86 and everything higher, or something like that.

If you're going to make Yet Another Distro of linux, you need either:

1) Yet Another Packaging System

or

2) a packaging system that sits above the distro level and can recognize the distro itself as a dependency.

I don't see anyone doing #2 real soon, unless this is a hidden attribute of APT or something. I think the lesson here is, if you don't like #1, stop making so many linux distros.

deb vs. rpm vs. gem

Posted Mar 11, 2004 3:41 UTC (Thu) by flewellyn (subscriber, #5047) [Link]

How about this?

3) A build system which sits above the package level and manages dependencies for the distribution. THis is kind of what Gentoo does with Portage. The "packages" themselves are just tarballs; dependencies are tracked by the ebuild scripts for each package, which also take care of details such as patching and building the package.

deb vs. rpm vs. gem

Posted Mar 10, 2004 15:09 UTC (Wed) by ewan (subscriber, #5533) [Link]

Umm... they do. Mandrake packages all have the suffix 'mdk' on their
release string, which makes the full name of Mandrake's current mc:
mc-4.6.0-6mdk.i586.rpm

deb vs. rpm vs. gem

Posted Mar 11, 2004 12:10 UTC (Thu) by ekj (guest, #1524) [Link]

You mean something like this:
$ rpm -qa | head -5
mktemp-1.5-11mdk
libpwdb0-0.61.2-3mdk
make-3.80-5mdk
gettext-base-0.13.1-1mdk
ifplugd-0.21b-1mdk
Okay, so it's not "mandrake" like you suggested, but rather "mdk", still same idea though.

deb vs. rpm vs. gem

Posted Mar 10, 2004 14:29 UTC (Wed) by NAR (subscriber, #1313) [Link]

Choice is good - but reinventing the wheel for n. time seems like a waste of time. Of course, if .gem has features that .rpm or .deb or .tar.gz or .tar.bz2 or .pkg or ... doesn't have, then it might be useful. I can see other ways to prevent the installation of non-distribution packages.

Bye,NAR

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