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
