Re: non-dpkg packaging systems (was: Re: `pms' from BOGUS (Debian vs. BOGUS) )
Bruce Perens writes:
> It sounds like using something like RPM to build our packages might
> be a good idea. I think the Debian binary package format is ahead of
> what Redhat is using, and you should consider adopting it. Perhaps
> we can arrive at a merge of the two.
I think this would be a good idea.
Marc Ewing writes:
> > It sounds like using something like RPM to build our packages might be a good
> > idea.
>
> It really is major time saver for the package developer. And being
> able to rebuild all the packages with a single command is pretty
> reassuring.
Quite (though in theory Debian has this too).
> I'd certainly be interested in talking about a merger (or at least
> some sort of cross-compatibility) of the formats. I think you are
> right, the debian binary package format (or perhaps more accurately,
> the debian database features) offer some advantages over rpms, mostly
> in the areas of conflicts, dependencies, and configuration. I haven't
> looked at dpkg in a long time so I may not be correct here.
dpkg has come a long way recently, and there are a few new features in
the pipeline.
> The rpm binary format has a few other cool things, like optional icons
> in the header (for use in our graphical package manager: glint). The
> header is tacked on to the head of the package uncompressed, which
> allows for very fast querying.
In Debian packages the `header' is currently compressed but separately
from the main archive. Before we make our public beta release I plan
to include support for a new binary package format, and I intend to
continue this plan.
In general, I'm planning to have an outer archive (ar or tar)
containing a small number of `files'. The first file would be a
package format marker and would contain the package format version &c;
the second would be a gzipped tarfile containing the various header
and control files, and the third would be the actual gzipped tarfile
containing the files in the package. I plan to make it possible to
add new parts, though the only part I plan to add in the foreseeable
future is one with a digital signature of the archive.
gzipping the tarfile containing the header info seems to be to be
worth the extra time extracting the information.
We have a separate database file, part of the distribution, which
contains selection-time information about each package, including its
conflicts and dependencies and a description.
> Another interesting feature is that packages (most often "subpackages"
> can "share" files - as long as the MD5 sums are the same in both
> packages (which they usually are if they are sibling subpackages).
> Installation and uninstallation of packages sharing a file does what
> you would want it to.
dpkg does not support this at the moment, though it could be made to.
What happens if you try to install two (sub)packages which contain
different versions of the same file ?
In Debian we handle the problem of several packages needing the same
files by having the `shared' files be in a separate binary package,
and using dependencies to ensure that they are installed.
> rpm is all written in perl5 so it should be pretty accessible. We've
> found that perl gives us decent speed, although the startup time is
> longer than we'd like.
dpkg is now written in C.
> Is there a current document somewhere that describes the debian
> package format and all the tricks it can do?
Unfortunately not really. There are a number of
specification/description text files as well as a rather out of date
full specification.
We're running on a tight schedule - perhaps we should defer this
discussion until post-release ?
Ian.
Reply to: