Re: corel

[Jeff Licquia <jeff@luci.org>]

On Sun, Dec 12, 1999 at 02:59:03PM -0600, Steven Pritchard wrote:

> On the other hand, I have yet to be convinced that the Debian package
> management system as a whole is superior to RPM.  From what
> (admittedly little) I've seen of Debian's packages, RPMs are cleaner
> and easier to build.  Yes, the dependencies could use a little work
> (why should someone necessarily need to know that a dependency on
> libhistory.so.3 means they need the readline package installed?), but,
> again, that's a tools issue, not an issue with the packaging system.

I will agree with this: Debian packages are much harder to write, and
are generally more complicated.

However, this complexity for the developer grants a lot of power to
the user.  For example, some of that complication allows Debian boxes
to be upgraded in-place between versions without requiring either a
boot to a pristine system or complex manual upgrading.  It also allows 
for some other cool things to be possible that would be difficult for
an all-volunteer project to do, such as architecture change tracking,
multiple pristine source tarballs per source package, a "lint"-like
tool that checks for packaging problems automatically, and so on.

There are automated tools to help the process along, though, such as
debhelper.

> RPM has several features that I *really* like.  First, there's the
> distinction between source packages and binary packages (which, oddly
> enough, is really more of a tool issue, since they use the same
> on-disk format), and the whole spec file notion of source and patches,
> which lets you easily build pristine source-based packages.  (Now, if
> only rpm was smart enough to take a URL for source and go fetch it for
> you...  Then rpm could build a package given only the spec file.)

On Debian, all you need is the package name:

$ apt-get -b source <package>

And yes, Debian supports source and binary packages, and the concept
of pristine sources.  Debian can even allow a package to be built with 
multiple pristine sources; X, for example, is this way.

> Second, I do like it that RPM packages, whether source or binary, are
> one file, rather than some funky directory structure or something.
> (I'm not pointing fingers at anything in particular here...  I've seen
> this on other operating systems.)  Now, if only the Red Hat people
> hadn't taken the easy route of using a cpio-based on-disk format (so
> they could just massage the file and exec cpio, rather than having to
> do work themselves), instead of an easier-to-manipulate tar archive...
> (It's a shame that nobody pointed out to the developers of rpm that
> GNU cpio can handle tar archives.)

Debian binary packages are single-file.

Debian source packages consist of several files: the .dsc (a text
file, which summarizes all the files in the package), one or more
pristine source files (in .tar.gz), and zero or more diff files.

> OK, I'll close with this.  Here's a (probably not complete) list of
> things I would like to see in the "perfect" package management system:

Let's see how we do:

>     1. Source and binary packages using one on-disk format.

You've got us there.  Binary .debs are ar files containing tar files,
and source packages are collections of files.  I wonder if it's been
thought about to "ar" all the source files together and create "source 
packages"?

>     2. Package tools that know how to build binary packages from
>        source packags.

As mentioned above, apt-get -b source <package>.

>     3. Single file package format based on tar.

Got that.

>     4. The ability to create "super-packages" containing several
>        independent packages.  (In other words, something similar to
>        the POSIX (AKA HP-UX) package spec's bundles, products, etc.,
>        but without all the cruft. :)

Got that.  ("apt-get install task-gnome-desktop" installs all the
stuff needed to do GNOME, for example)

>     5. Package tools that are smart enough to let you implement some
>        kind of policy for keeping local copies of files that have been
>        upgraded or removed.  In other words, some way to make it just
>        a little easier to recover when you screw yourself by removing
>        a package like, say, mount.  (Has everybody here my story about
>        that?  :-)

Got that (I think - diversions?).

>     6. Preferably a tool that was flexible enough to do something sane
>        with foreign packages (and maybe even provide front-ends that
>        implement their functionality/command-line arguments for
>        transition purposes).

Got that.  (alien)

> All of that would be pointless though without a distribution that had
> a hard, fast list of requirements for packages...

Got that, too.  Check the Debian policy manual and packaging manual if 
you're curious (www.debian.org, look in "Developer's Corner").

--
To unsubscribe, send email to majordomo@luci.org with
"unsubscribe luci-discuss" in the body.