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

Re: [hackers-il] RPM vs. DEB - which is better and why?

Expand Messages
  • 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 1 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 2 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.