Re: some statistics on using bz2 for packages
On Sun, Oct 31, 1999 at 01:10:02PM +1000, Anthony Towns wrote:
> On Sat, Oct 30, 1999 at 05:50:50PM -0400, Ben Collins wrote:
> > I took the (immense amount of) time do some real testing on using bz2 for
> > packages.
>
> Just a note that no one seems to have mentioned: this requires making
> bzip2 essential, at least for packages compressed with bzip2. Having
> those packages Pre-Depend on bzip2 isn't even entirely strong enough ---
> dpkg can't even cope with a dpkg-dev --contents request without bzip2
> installed. Adding `dpkg [Pre-]Depends: bzip2' would fix it, though. (dpkg
> doesn't currently formally depend on gzip, however)
bzip2 and libbz2 together are almost 400k (260k for the packages), so yes,
this is a small issue (I don't see why bzip2 can't be essential anyway,
since tar already requires it for some functionality).
The issue of how to handle the dependency on a dpkg that will unpack them
is handled internally by dpkg. Packages that use the new format would have
a Package format of 3.0, which with an older dpkg would give an error that
says "you need a newer dpkg". Since all essential packages get upgraded
first (and essential packages shouldn't use the bz2 package format), then
dpkg will get upgraded before it is needed for the rest of the packages.
Atleast this is the scenario with apt-get.
Also, whether or not the package gets compressed with bz2 is handled by
the debian/rules file (either calling dpkg-deb directly or passing the
args via dh_builddeb). So we have this at the maintainers control, not the
builder who happens to package it (ie. ports and NMU's). This maintains a
certain stability as to what gets compressed with bz2 and what doesn't
(since the package maintainer knows whether or not it will do any good).
OTOH, using bz2 for source is not as much of a problem, so they can be
compressed away without worry, so long as bzip2 is essential (then it's
always there).
Ben
Reply to: