Re: [ANNOUNCE] experiemental dpkg available
On Wed, 27 Oct 1999, Ben Collins wrote:
> ftp-admins say about dinstall/archive being able to handle this with
> current scripts.
Unfortunately current source archives cannot be converted because
signatures are applied to the compressed archives and not their data :<
IMHO we should move to getting widespread bz2 use for source archives
ASAP, it will help slow archive growth [11.1G today!]
> Dpkg-deb will also automatically detect the compression type when
> unpacking the .deb. Note that the new .bz2 format will have a package
> format version of "3.0" so that older dpkg's that don't support this will
We need some sort of sane upgrade path for this I think, or don't use it
at all in potato.
At least, APT will properly order a sequence like 'install dpkg foo' in
all cases *unless* foo is an essential package (or a dependent of an
essential package), in that instance the ordering is difficult to predict
in advance - particularly 'install dpkg libc6' will be reversed.
People using any other method will have to run the install multiple times,
and people may be alarmed that 'apt-get install foo' no longer works
without an unmentioned requirement to install a new dpkg.
The best thing I can think of to deal with this is to propogate the .deb
format version to the Packages.gz file and add a special tag to dpkg
indicating which version it supports - smart tools (ie APT) can check that
and ensure that dpkg is magically brought in if required. Doing this would
also solve the Long Filename issue [which is technically a change in .deb
format].
Furthermore, I would propose that this bz2 function not be extensively
used, except in cases where some of the following are true:
a) The package is expected to be only usefull on a high powered system
b) The package gets substantial savings in size.
c) The user base for the package is small
Remember, bunzip2 needs a meg of scratch memory and a huge wack of CPU
power, small machines cannot handle it.
Jason
Reply to: