Debian Planet

Welcome to Debian Planet


All your woody are (not quite, but very very very soon) belong to us.
Main Menu

  • Home

  • Topics

  • Web Links

  • Your Account

  • Submit News

  • Stats

  • Top 10

  • Debian

    These are important Debian sites one should not be without!

  • Official Debian site

  • Package search

  • Mailing list archives

  • Bug reports

  • Debian on CD

  • Unofficial woody CD ISOs

  • Unofficial APT sources

  • Developers' Corner

    Other great Debian news sources:

  • Debian Weekly News

  • Kernel Cousin Debian

    (Debian mailing lists digested)
  • Community Groups

    Need help? You're not alone on this planet.

  • debianHELP

    (User support site)

  • Debian International



  • EsDebian


  • DebianWorld


  • MaximumDebian


  • DebianUsers


  • Debian-BR


  • IRC

    The place to get help on a Debian problem (after reading docs) or to just chat and chill is #debian on

    Many of the Debian Planet staff live there so pop by and say hello.

    Wanna write?

    Got that latest or greatest scoop? Perhaps you have some important news for the Debian community? Submit a news item!

    Or perhaps you've written a rather ground breaking insight into some aspect of Debian and you feel compelled to share it with others? Knock up a longer editorial article and send it to the editors.


    DP is sponsored by Xinit Systems and

    Domains paid for and hosted by

    Buy your Debian merchandise at

    Who's Online

    There are currently, 78 guest(s) and 6 member(s) that are online.

    You are Anonymous user. You can register for free by clicking here.

    What are the *real* .deb and .rpm differences
    Contributed by arcterex on Wednesday, June 13 @ 10:07:26 BST

    Package Management
    This has been thrown around by a few of the guys here for a while, but what are the *real* differences between debs and rpms? They both basically do the same thing, have pretty much the same options and switches, yet create a rift in the linux community between the debian based distros and the rpm based distros.

    Is the difference really that big, or is it mostly a religious preference? I know that on the backend they both work off a different database system, and the formats are different, but how hard would it be to make a redhat system work via dpkg/apt? Could it be done? On the flipside, could a debian system be made to work with rpms (I'm talking natively, not via alien).

    Something that seems would be advantagous of the linux community would be a common packaging format. .deb has some advantages, and .rpm has some. Both camps can put efforts into creating feature compatibility between the two (signed packages, encryption, etc etc), but that may be wasted effort when both camps could work towards making the distro work with ONE of the two formats.

    Related Links

  • Comparison by Joey Hess
  • More about Package Management
  • News by rob

    Most read story about Package Management:
    What are the *real* .deb and .rpm differences

    Last news about Package Management:

    Printer Friendly Page  Send this Story to a Friend
  • "What are the *real* .deb and .rpm differences" | Login/Create Account | 76 comments

    The comments are owned by the poster. We aren't responsible for their content.

    Re: What are the *real* .deb and .rpm differences (Score: 3, Informative)
    by zoltan on Wednesday, June 13 @ 13:06:20 BST
    (User Info)

    It isn't so much as the actual files but the backend that supports it. dpkg and apt-get are a much more powerful combo than say rpm and dpkg/apt handles dependancies much better and you end up getting a cleaner system when moving between distributions (ie potato -> sid). Cant say the same for redhat and friends.

    Thats just my .02

    [ No Comments Allowed for Anonymous, please register ]

    Re: What are the *real* .deb and .rpm differences (Score: 1, Insightful)
    by Anonymous on Wednesday, June 13 @ 15:21:04 BST

    Moving to a common packaging system would be GREAT. The only problem I can see would be getting people to actually follow through with it. I doubt this will happen, even if the LSB made a packaging format I don't think redhat would move away from RPM.

    [ No Comments Allowed for Anonymous, please register ]

    Re: What are the *real* .deb and .rpm differences (Score: 5, Informative)
    by Robot101 (robot1<zero> on Wednesday, June 13 @ 16:16:45 BST
    (User Info)

    The package format, in terms of a bunch of files in some kind of tar/ar/gzip munchage, is not very different. That's why alien exists, and works. If you don't mind throwing Debian policy to the wind, you can fill your system with crap by aliening a lot of RPMs and installing them.

    The difference is in the other part of the package, the control info, the maintainer scripts, and the package relationships. Debian has more package relationships, depends, suggests, conflicts, replaces, provides, etc, which would probably render debs uninstallable on rpm systems, which always have fucked dependencies anyway, or let you install a deb on an rpm system when the deb wouldn't natively want to install. Debian's maintainer scripts would have a hard time working on redhat systems, calling on update-rc.d, update-inetd, etc etc.

    The real difference that prevents a common format is a difference in approach, Debian vs RedHat. We have policy, packages that are upgradable from way back when, strict standards, and right ways to do things, and RedHat have... a bunch of files dropped any-which way with some GUI configurator. A common package format cannot resolve these differences, as the two approaches are alien to each other. Considering the number, and quality of RPMs on the 'net, I wouldn't want to install them on my box anyway. If you see any .debs lacking, let me know and if it's good, I'll package it for you.



    [ No Comments Allowed for Anonymous, please register ]

    Re: What are the *real* .deb and .rpm differences (Score: 2, Interesting)
    by Anonymous on Wednesday, June 13 @ 16:19:34 BST

    Common packaging format is not a good idea.

    Currently say SuSE and RedHat both use rpm and you see

    how it looks like . One big mess.

    Debian should stick to what it has (or develop something

    on its own) and not go into some 'common formats' or whatever.

    Debian has taken different roads a few times in the past, and it

    always proved as technically superior.

    [ No Comments Allowed for Anonymous, please register ]

    Re: What are the *real* .deb and .rpm differences (Score: 5, Informative)
    by ElectricElf (dbarclay10 at yahoo dot ca) on Wednesday, June 13 @ 16:46:03 BST
    (User Info)

    The package formats themselves are fairly simple.

    Debian's .deb: An 'ar' file, containing three tar.gz archives. Two of those .tar.gz's are of particular interest - data.tar.gz, and control.tar.gz. data.tar.gz contains the files which will actually be installed to the filesystem. control.tar.gz contains the package headers/description, the various scripts that will be run, so on and so forth.

    Red Hat's RPM: An RPM is a modified 'cpio' archive. The modifications are fairly straightforward - it takes about twenty lines of C code to convert an RPM 'cpio' archive to a regular 'cpio' archive. The changes allow the archive to start with package control data, such as scripts and headers(dependency information, package description - similar to control.tar.gz).

    There are advantages to each. On almost every system you go to, you should be able to open up a .deb without any trouble - 'ar', 'tar', and 'gzip' are everywhere. However, in order to get information about the package, the 'ar' archive needs to be unpacked, and then control.tar.gz. That can be time-consuming on a local machine, and in order to get information from a remote package, you need to download the whole thing.

    RPMs, though, need a special utility, albeit small, to convert the archive into standard 'cpio' format. On the other hand, you only need to download the first few thousand bytes of a remote RPM to know everything about it.

    What *really* makes .debs better than RPMs in many cases(and I apologize if you disagree - this is just in my experience) is the time spent by the maintainer. Red Hat simply can *not* put a lot of effort into each and every package. There are too many included on the CDs, and they have only so many people. On the other hand, most Debian maintainers handle one or two packages only. They generally only package stuff they're very interested in, and hence (usually) spend more time on them, and make sure that they're quality packages.

    The Debian build system is also rather complex and impressive. debhelper, debconf, you name it, it makes putting together complex, quality, policy-compliant packages easier. So not only do Debian maintainers usually care more about their packages, but they have tools at hand to significantly ease their burden.

    My six cents 🙂

    [ No Comments Allowed for Anonymous, please register ]

    Re: What are the *real* .deb and .rpm differences (Score: 0)
    by Anonymous on Friday, June 15 @ 15:48:44 BST

    What about the conectiva project to combine rpm and deb?

    Does this make .rpm as good as .deb ?

    Richard Bos

    [ No Comments Allowed for Anonymous, please register ]

    Re: What are the *real* .deb and .rpm differences (Score: 0)
    by Anonymous on Friday, June 15 @ 19:07:31 BST

    I'm a real Debian user. can't say it any other way...

    Yesterday i was curious to that strange thing called Redhat, so I installed it on top of my Debian system. Never again, Debian is now back up, and apt-get is getting all those kewl new .deb's (long live broadband :o)

    But anyway, what's the real difference between .deb's and rpm's?

    Once you use deb's, you don't want (or need) anything else. It's so fscking easy, it makes you lazy. Rpm's are just crap at dependancy's, and Redhat doesn't have anything close to the ease of dpkg.

    Anyone who still uses rpm's, just try debian. I'll bet you'll never want anything else!

    [ No Comments Allowed for Anonymous, please register ]

    So, 1) Policy, and 2) What else? (Score: 2, Insightful)
    by Anonymous on Friday, June 15 @ 20:56:20 BST

    The one thing everyone is agreeing on is policy. Debian fits together a lot better because of its very careful policy regarding file locations, configuration, dependency naming, virtual packages, etc.

    The nice thing about .debs is that most of them - even third-party ones - actually follow this policy, so a random .deb is likely to work.

    RPM is known to be more of a mess. It appears that the LSB could learn a lot from the Debian policy document.

    However, imagine a fantasy land where all the gaps in RPM standards are filled by a sensible packaging policy - be it the Debian policy or an equivalent LSB policy.

    What, then, are the remaining differences between .deb and .rpm? Is there any actual conflict between what existing RPM policy there is, and the Debian policy? What differences are enforced by the tools and formats?

    One big difference I am aware of is that RPMs tend to declare dependencies on files, like /usr/lib/sendmail rather than a virtual package like mail-transport-agent.

    Also, I seem to recall that RPM installation is supposed to be totally non-interactive. No pausing and asking questions like dpkg does.

    Does RPM support an apt-listchanges equivalent?

    While I'm at it, let me mention my (least) favourite failure in the Debian packaging tools: inadequate logging.

    I want all those installation messages and alerts to be archived somewhere - preferably for the life of the package installation. I want to be able to ask, in response to "what happened to $FOO? It worked on Tuesday but is totally broken today!", for a list of changes made (debconf and package installs) since Tuesday.

    I also want all removed or replaced packages to be kept for some configurable time so I can roll back to a known working version even if has deleted it.

    This is more of a tool issue than a package-format issue, but does RPM handle these things any better?

    [ No Comments Allowed for Anonymous, please register ]

    debconf; why we must NOT standardize (Score: 3, Interesting)
    by hazelsct ( on Friday, June 15 @ 21:09:31 BST
    (User Info)

    I'll second most of the opinions posted until now, and emphasize one point of particular importance to me: debconf.

    For the non-Debian users, debconf is the Grand Unified Install Shield Wizard (no offense to the debconf authors, that's the closest external equivalent I could think of) of the entire distribution. When you get 200 packages, between the download and install steps, they are all scanned for configuration information, and configuration questions will be asked for each one. This covers everything from which X driver to use, to which Kerberos realm you live in, to where you downloaded the RealPlayer RPM (so the Debian installer package can intelligently unpack it in a Debian-friendly way).

    Debconf is highly configurable too. The questions are asked via one of four different frontends determined by the user (text, editor, dialog, slang; choose noninteractive to avoid the questions and use default answers; there used to be gtk+ and Progeny has a gnome control panel frontend). And there are four levels of qustion priorities: low, medium, high and critical; the user chooses below which level to accept default answers. And it's internationalized: the package can have question text in multiple languages and the closest one to the users' will be displayed automagically.

    No other distribution or package format of any kind, free or proprietary, has anything like this, and it is one of Debian's great strengths.

    Furthermore, it shows why we must NOT standardize around a particular format. If we had stardardized around an earlier .deb format, we could not have added the debconf system (with some major kludges).

    So yes, Debian has the best packages because seven hundred developers put in the time to make them that way, or if they don't, they're shamed with release-critical bugs and their packages get excluded from stable. But there are important feature differences as well, which make it easier to write packages (update-rc.d and update-alternatives were mentioned), and which make .deb a vastly more powerful package format for the end-user than any other.

    [ No Comments Allowed for Anonymous, please register ]

    Re: What are the *real* .deb and .rpm differences (Score: 3, Insightful)
    by sEEKz on Saturday, June 16 @ 12:12:43 BST
    (User Info)

    It's not only in the package format it is in the system which supports it.

    One of the strongest differences I find, is managebillity.

    The Easiest way is to demonstrate it with an example. Recently the BIND-8.2 bug was discovererd, well I had a couple of Debian (potato r2) servers running this version, only thing I had to do on these machines was:

    # apt-get update

    # apt-get install bind (could be upgrade though)

    I did this on about 6 servers in 15 minutes or so (they all had ISDN, that's why it took so long 🙂

    I also had a red hat 5.2 machine somewhere running, well upgrading sucks, I first had to know what the exact name of the package was by going onto the ftp server and look for it's exact name. next thing I had to do:

    # rpm -U ftp://up....../bind-x.rpm

    this also took me about 15 minutes.

    I don't have this problem with dpkg/apt, it knows where packages are stored, hence you can give multiple locations, wich makes it possible when one location fails it can look on another which has the same packages. This only works of course if you've got it configured.

    I have to admit if i worked more with Red Hat I knew the location by forehand, but still had to look for the exact name of the package before I had to install it. This is something I don't want to do, it takes a lot of time and it is easy to make mistakes.

    Another thing pops here up and that's rpm *only* supports installing from file or ftp, apt knows file, ftp, http, nfs (well any kind of network sharing linux knows of), cdrom, copy.

    Debian Package Hackers: Keep up the good work!

    [ No Comments Allowed for Anonymous, please register ]

    .deb's are useable without package-managers (Score: 1, Informative)
    by Anonymous on Saturday, June 16 @ 17:11:02 BST

    Ever tried to get the content of an package

    on solaris, or when your computer is

    screwed up, or when starting from some rescue

    disk? With .rpm one can forget it.

    There might be some programs zu unpack rpm,

    but one can more easily install rpm itself.

    With .deb you do

    ar -x $DEBNFILE

    tar -xzf data.tar.gz

    and you have it.

    [ No Comments Allowed for Anonymous, please register ]

    Re: What are the *real* .deb and .rpm differences (Score: 1, Informative)
    by wichert on Tuesday, October 30 @ 12:24:30 GMT
    (User Info)

    One of the interesting differences that almost

    nobody notices is the way maintainer scripts are

    handled. Both package formats have similar scripts,

    but the moments during the package installation/upgrade/removal processes they are called are different. The ordering dpkg uses

    guarantees that packages can finetune things at

    various essential moments and handle rollback on

    errors cleanly. For rpm that is not possible.

    [ No Comments Allowed for Anonymous, please register ]

    Re: What are the *real* .deb and .rpm differences (Score: 1)
    by roady on Wednesday, November 14 @ 05:17:44 GMT
    (User Info)

    The real benefit that rpm has over dpkg/deb/whatever you want to call it, IMHO is rpmlib. Which makes it trivial to develop applications which install rpms, query the rpm db, etc, etc, etc. dpkg lacks this bigtime, which is the only thing holding it back from being a superior packaging format/tool.

    [ No Comments Allowed for Anonymous, please register ]

    Based on: PHP-Nuke

    All logos and trademarks in this site are property of their respective owner. The comments are property of their posters, all the rest © 2000 by Debian Planet

    You can syndicate our news using the file backend.php.