Loading ...
Sorry, an error occurred while loading the content.

RPM vs. DEB - which is better and why?

Expand Messages
  • Omer Zak
    On the other day I read an article (http://www.manageability.org/blog/stuff/the-architecture-of-participation/view - whose subject is The Architecture of
    Message 1 of 4 , Sep 29, 2004
    • 0 Attachment
      On the other day I read an article
      (http://www.manageability.org/blog/stuff/the-architecture-of-participation/view
      - whose subject is "The Architecture of Participation"). Among other
      things, it says "Just ask Red Hat, whose sole main contribution to the
      Linux world has been RPM.".

      This leads me to question whether RedHad provided service or disservice
      to the world by providing RPM (rather than, say, reusing DEB).

      Does anyone have the experience and intimate familiarity with both
      packaging formats needed to answer the above question.
      --- Omer
      My own blog is at http://www.livejournal.com/users/tddpirate/

      My opinions, as expressed in this E-mail message, are mine alone.
      They do not represent the official policy of any organization with which
      I may be affiliated in any way.
      WARNING TO SPAMMERS: at http://www.zak.co.il/spamwarning.html
    • omer mussaev
      ... (http://www.manageability.org/blog/stuff/the-architecture-of-participation/view ... This is rather long email... A few years ago I had had to undrestand
      Message 2 of 4 , Oct 3, 2004
      • 0 Attachment
        --- Omer Zak <omerz@...> wrote:

        > On the other day I read an article
        >
        (http://www.manageability.org/blog/stuff/the-architecture-of-participation/view
        >
        > - whose subject is "The Architecture of
        > Participation"). Among other
        > things, it says "Just ask Red Hat, whose sole main
        > contribution to the
        > Linux world has been RPM.".
        >
        > This leads me to question whether RedHad provided
        > service or disservice
        > to the world by providing RPM (rather than, say,
        > reusing DEB).
        >
        > Does anyone have the experience and intimate
        > familiarity with both
        > packaging formats needed to answer the above
        > question.
        >

        This is rather long email...

        A few years ago I had had to undrestand the internals
        of RPM for my employer.
        Being a Debian user since 1996, I could not help but
        to compare between
        the two formats, so I think I may be qualified to
        answer your question.


        Both systems allow a developer to create packages for
        an application.
        Both systems allow the developer to limit intended use
        of the packages
        to specific architecture/operating system.
        Both systems provide interface to explicitly specify
        dependencies that
        the packages has as well as means to enforce these
        dependencies.

        However, there are substantial differences:



        Package Construction
        ========================================================================


        RPM system assumes that there are vendors that create
        packages, and then
        there are users that install these packages. There are
        dependencies
        between the packages; it is role of distribution
        authors to create set
        of packages that mutually satisfy their respective
        dependencies.
        Each RPM package has its own "spec" file - a
        specification of
        files that are included in the package, dependencies
        that are to be met,
        contact information for support/payments, scripts that
        should be run
        whenever the package is installed/uninstalled,
        verification routines
        etc.

        In addition to packaging, an RPM system provides means
        for software
        building. The very same "spec" file contains rules for
        makefile
        generation. During development phases the developers
        may find very
        convinient to create RPM specifications once and have
        the compile
        server produce installable distributables after each
        build. It has a
        lot of positive effect on software quality etc.

        This model is well suited for commertial software
        vendors that prefer
        to control as much of the distribution/package
        creation process as
        possible.



        Debian system assumes much more of the development
        process:

        In addition to developers that create software, there
        are package
        maintainers. While a developer may be a package
        maintainer of software
        he develops (e.g. moshez@... ), roles are
        definitely different.
        It's the package maintainer who creates a package,
        and, as such, he
        must be responsible for any problems the package may
        introduce (unmet
        dependencies, readiness for new foundation libraries,
        support for I18N
        or IDN or whatever).
        However, unlike RPM world, in order to put the package
        into
        distrubution, a master list of packages must be
        created. This list
        (maintained by "Debian Czars") represents a snapshot
        of a system state.

        The DEB system does not specify any build rules. It is
        possible, of
        course, to deploy whatever source change managment
        system the developer(s)
        may find appropriate to create the software. One may
        find it very nice,
        and, to some extent "right" that a package development
        does not force
        any "mechanism" of software construction upon a
        developer, but allows
        the package maintainer to decide.




        Package Installation
        ========================================================================

        Both systems have a client software that is
        responsible for installing
        software, removing software, performing software
        updates and quering the
        system about installed software packages.

        Both systems support relocateable packages - packages
        that do not insist
        on specific location.

        There is two substantial differences between the two:

        RPM system disallows user input during
        installation/deinstallation. The
        documentation claims that user input is disallowed to
        support unattended
        installations. It may, however, force the developers
        to invent their own
        solutions once they do have to ask the user some
        questions. The tradeof
        beteween unattended installation that requires
        post-installation
        configuration and atteneded installation that doesn't
        require any is
        indeed an architectural issue.


        Another difference is the "alternatives"/"virtual
        packages" approach
        taken by DEB. The idea is that if some software needs
        a web server, than
        it need a web server, not nessesarily "apache" or
        "boa" or "goahead".
        Likewise, if a user wants a vi, he may be satisfied by
        nvi, by vim or by
        viper. This kind of a "is a" relationships between
        packages is answered
        in DEB sybsystem in a elegant way - there is a
        /etc/alternatives
        subdirectory in a user's filesystem. Each package that
        provides
        functionality of some generic software (e.g. vim that
        "provides" vi)
        registers itself in that /etc/alternatives directory
        as an "alternative"




        Package Maintainence
        ========================================================================

        RPM system stores the package metainformation in a
        database-like
        structure. This allows performing queries in a
        SQL-like manner.

        DEB system stores the package information as a set of
        plain text files.
        This scheme is very robust, and allows using system
        tools to find out
        the metainformation.

        > Omer
        > My own blog is at
        > http://www.livejournal.com/users/tddpirate/
        >
        > My opinions, as expressed in this E-mail message,
        > are mine alone.
        > They do not represent the official policy of any
        > organization with which
        > I may be affiliated in any way.
        > WARNING TO SPAMMERS: at
        > http://www.zak.co.il/spamwarning.html
        >



        =====
        --
        o.m.



        __________________________________
        Do you Yahoo!?
        Yahoo! Mail Address AutoComplete - You start. We finish.
        http://promotions.yahoo.com/new_mail
      • Tzafrir Cohen
        ... Much an overstating. And there are some layers on top of rpm to which RH has not contributed enough (apt/yum/whatever) as it was busy with its own up2date
        Message 3 of 4 , Oct 4, 2004
        • 0 Attachment
          On Wed, Sep 29, 2004 at 09:34:00PM +0200, Omer Zak wrote:
          > On the other day I read an article
          > (http://www.manageability.org/blog/stuff/the-architecture-of-participation/view
          > - whose subject is "The Architecture of Participation"). Among other
          > things, it says "Just ask Red Hat, whose sole main contribution to the
          > Linux world has been RPM.".

          Much an overstating.

          And there are some layers on top of rpm to which RH has not contributed
          enough (apt/yum/whatever) as it was busy with its own up2date and with
          bloating rpm...

          >
          > This leads me to question whether RedHad provided service or disservice
          > to the world by providing RPM (rather than, say, reusing DEB).

          RPM was designed before DEB. So the question is rather moot.

          My 2c regarding rpm vs. deb:

          The debian build sytem is much more complex, but more straight-forward
          in its approach.

          With rpm it is much easier to get started. And it is also much easier to
          get a recontructable package: all the builng is done in a separate tree,
          not just the insallation.

          Ah: and with debs you never have to mess with cpio.

          >
          > Does anyone have the experience and intimate familiarity with both
          > packaging formats needed to answer the above question.
          > --- Omer
          > My own blog is at http://www.livejournal.com/users/tddpirate/
          >
          > My opinions, as expressed in this E-mail message, are mine alone.
          > They do not represent the official policy of any organization with which
          > I may be affiliated in any way.
          > WARNING TO SPAMMERS: at http://www.zak.co.il/spamwarning.html
          >
          >
          >
          >
          >
          > Yahoo! Groups Links
          >
          >
          >
          >

          --
          Tzafrir Cohen +---------------------------+
          http://www.technion.ac.il/~tzafrir/ |vim is a mutt's best friend|
          mailto:tzafrir@... +---------------------------+
        • Tzafrir Cohen
          ... An rpm source package consists of typically one source tarball, a spec file, and optionally a number of patches. The spec file is basically equivalent to
          Message 4 of 4 , Oct 6, 2004
          • 0 Attachment
            On Sun, Oct 03, 2004 at 06:38:57AM -0700, omer mussaev wrote:
            >
            >
            > --- Omer Zak <omerz@...> wrote:
            >
            > > On the other day I read an article
            > >
            > (http://www.manageability.org/blog/stuff/the-architecture-of-participation/view
            > >
            > > - whose subject is "The Architecture of
            > > Participation"). Among other
            > > things, it says "Just ask Red Hat, whose sole main
            > > contribution to the
            > > Linux world has been RPM.".
            > >
            > > This leads me to question whether RedHad provided
            > > service or disservice
            > > to the world by providing RPM (rather than, say,
            > > reusing DEB).
            > >
            > > Does anyone have the experience and intimate
            > > familiarity with both
            > > packaging formats needed to answer the above
            > > question.
            > >
            >
            > This is rather long email...
            >
            > A few years ago I had had to undrestand the internals
            > of RPM for my employer.
            > Being a Debian user since 1996, I could not help but
            > to compare between
            > the two formats, so I think I may be qualified to
            > answer your question.
            >
            >
            > Both systems allow a developer to create packages for
            > an application.
            > Both systems allow the developer to limit intended use
            > of the packages
            > to specific architecture/operating system.
            > Both systems provide interface to explicitly specify
            > dependencies that
            > the packages has as well as means to enforce these
            > dependencies.
            >
            > However, there are substantial differences:
            >
            >
            >
            > Package Construction
            > ========================================================================
            >
            >
            > RPM system assumes that there are vendors that create packages, and then
            > there are users that install these packages. There are dependencies
            > between the packages; it is role of distribution authors to create set
            > of packages that mutually satisfy their respective dependencies.
            > Each RPM package has its own "spec" file - a specification of
            > files that are included in the package, dependencies that are to be met,
            > contact information for support/payments, scripts that should be run
            > whenever the package is installed/uninstalled, verification routines
            > etc.

            An rpm source package consists of typically one source tarball, a spec
            file, and optionally a number of patches. The spec file is basically
            equivalent to the debian/ subdirectory.

            See also http://www.rpm.org/max-rpm/ch-rpm-philosophy.html

            >
            > In addition to packaging, an RPM system provides means for software
            > building. The very same "spec" file contains rules for makefile
            > generation. During development phases the developers may find very
            > convinient to create RPM specifications once and have the compile
            > server produce installable distributables after each build. It has a
            > lot of positive effect on software quality etc.

            IMHO rpm is much more pedantic than deb about creating a reproducable
            build.

            >
            > This model is well suited for commertial software vendors that prefer
            > to control as much of the distribution/package creation process as
            > possible.
            >

            Why only for them?

            >
            >
            > Debian system assumes much more of the development
            > process:
            >
            > In addition to developers that create software, there are package
            > maintainers. While a developer may be a package maintainer of software
            > he develops (e.g. moshez@... ), roles are definitely different.
            > It's the package maintainer who creates a package, and, as such, he
            > must be responsible for any problems the package may introduce (unmet
            > dependencies, readiness for new foundation libraries, support for I18N
            > or IDN or whatever).

            You probably don't follow the "rpm" distros. They generally have such
            maintainers. Though they tend to be full-time developers with many
            packages in responsibility.

            > However, unlike RPM world, in order to put the package into
            > distrubution, a master list of packages must be created. This list
            > (maintained by "Debian Czars") represents a snapshot of a system state.

            This is something completely different. The people of Debian don't all
            work at one company and lack quick methods of communication. Thus they
            had to establish more formal methods for everything. But then again, you
            have had Redhat RawHide (a snapshow of the development distribution) for
            years.

            >
            > The DEB system does not specify any build rules.

            Huh? I thought that this was the point to say debian/rules ;-)

            The rules file is a regular makefile. It may contain anything a makefile
            can contain. However to maintain consistency there are some standard
            commands at the disposal of the package developer. the advantage of
            using those commands is that when the policy of the distro changes, you
            only have to rebuild the package.

            Not surprisingly, RPM had such a thing since day one. THe RPM spec file
            is written in its own text processing language (see
            /usr/share/doc/rpm*/MACROS , IIRC) . Many macros are not even written in
            the spec file and run by the rpm command.

            There are a number of problems with that system:
            1. highly undocumented.
            2. The lack of standard macros accross distros

            None eof the two is a generic problem with the system, though.

            > It is possible, of
            > course, to deploy whatever source change managment system the developer(s)
            > may find appropriate to create the software.

            One distro that does so is PLD (Polish(ed) Linux Distribution). Take a
            look at their rpm changelogs.

            On the other hand, since you raise that subject, one of RedHat's
            veterans is now working on a system that combines source control,
            packageing and the equivalent of apt. Anybody with the URL here?

            > One may find it very nice,
            > and, to some extent "right" that a package development does not force
            > any "mechanism" of software construction upon a developer, but allows
            > the package maintainer to decide.
            >
            >
            > Package Installation
            > ========================================================================
            >
            > Both systems have a client software that is responsible for installing
            > software, removing software, performing software updates and quering the
            > system about installed software packages.
            >
            > Both systems support relocateable packages - packages that do not insist
            > on specific location.

            Is this feature supported in practice? Used in practice?

            >
            > There is two substantial differences between the two:
            >
            > RPM system disallows user input during installation/deinstallation. The
            > documentation claims that user input is disallowed to support unattended
            > installations. It may, however, force the developers to invent their own
            > solutions once they do have to ask the user some questions. The tradeof
            > beteween unattended installation that requires post-installation
            > configuration and atteneded installation that doesn't require any is
            > indeed an architectural issue.
            >

            There is one other issue here: a naive packager would only think about
            the first post-nstallation. Maybeeven about an uninstallation. But what
            about an upgrade?

            Another interesting anecdote: up until now, Debian has had no automatic
            instllation procedure. The new Debian installer filnally have something
            (a preseed file) and it is still highly immature. Its main problem is
            that it reacts poorly to changes.

            As a result, I believe that there is much bigger a chance for debian
            installation to fail in the middle, as this is less disturbing for the
            developers.

            >
            > Another difference is the "alternatives"/"virtual packages" approach
            > taken by DEB. The idea is that if some software needs a web server, than
            > it need a web server, not nessesarily "apache" or "boa" or "goahead".
            > Likewise, if a user wants a vi, he may be satisfied by nvi, by vim or by
            > viper. This kind of a "is a" relationships between packages is answered
            > in DEB sybsystem in a elegant way - there is a /etc/alternatives
            > subdirectory in a user's filesystem. Each package that provides
            > functionality of some generic software (e.g. vim that "provides" vi)
            > registers itself in that /etc/alternatives directory as an "alternative"
            >

            The laternatives is not part of deb. As such it has been adopted by
            other distros, at least Mandrake and RH/Fedora.

            Virtual packages is something different. Having them is mostl a matter
            of policy (forcing all the relevant packages to depend on "httpd"
            because there may be actually an http server besides apache. I figure
            that for Mandrake or RedHat this was not really an issue. Maybe for
            SuSE).

            Something that rpm does lackain that field is a dependency on "a || b" .

            > Package Maintainence
            > ========================================================================
            >
            > RPM system stores the package metainformation in a database-like
            > structure. This allows performing queries in a SQL-like manner.

            The packages are in a Berkely DB.
            The downside is that rpm requires that specific library just to get
            going. The internal database formay has changed a number of times and
            this was a pain.

            The upside is 'rpm -qfl' and the like.

            >
            > DEB system stores the package information as a set of plain text files.
            > This scheme is very robust, and allows using system tools to find out
            > the metainformation.

            --
            Tzafrir Cohen +---------------------------+
            http://www.technion.ac.il/~tzafrir/ |vim is a mutt's best friend|
            mailto:tzafrir@... +---------------------------+
          Your message has been successfully submitted and would be delivered to recipients shortly.