Why the .deb format?
"BC" == Billy Chow <firstname.lastname@example.org> writes:
BC> Dear all,
BC> This is the question I always wanted to ask. Are there advantages to
BC> the use of .deb format for debian packages? Why is .tgz
I think this is a good question.
According to `deb(5)', Debian-0.93 packages have the following
version number (0.93...), followed by newline.
number of characters occupied by control area
expressed in decimal, followed by newline.
compressed gzipped ustar formatted archive. Must
contain file named control. May optionally contain
files named: conffiles, preinst, prerm, postint,
files archive area:
compressed gzipped ustar formatted archive. [with
file structures designed to be unpacked in the root
Given this logical structure, you seem to me to be asking if it
would not be at least as appropriate to gzip these four sections
together whilst the third and fourth sections were still in their
In the absence of any file corruption, doing it that way would
obviously make it more costly to do some things which can be done very
easily under the present scheme (like checking the dpkg version
number, for instance) so I guess the question becomes would doing it
that way be any better i.t.o. providing safeguards against file
As matters stand, if after the first readline has been issued, the
second readline returns a positive integer NC, the result of reading
the succeeding NC characters (bytes?) is I think safeguarded (assuming
it does not run off the end of the file) by the fact that it has to
pass `gunzip -t'; the remainder of the file must also pass `gunzip
And AFAIK there is one and only one place where a sequence of
bytes consisting of two gzipped files which have been concatenated can
be split into two such that both parts are gzip files.
For example, as an experiment, I just now copied the file
`ae-493-6.deb' to a file named `test.deb', loaded the latter into
emacs, and deleted a random handful of bytes from somewhere near the
middle of the files archive area section, just to see how `dpkg
--contents' would react.
# dpkg --contents test.deb
------------------------ quote -------------------------
drwxr-xr-x root/root 0 Oct 2 18:35 1995 ./
drwxr-xr-x root/root 0 Oct 2 18:35 1995 usr/
drwxr-xr-x root/root 0 Oct 2 18:35 1995 usr/doc/
drwxr-xr-x root/root 0 Oct 2 18:35 1995 usr/doc/copyright/
-rw-r--r-- root/root 5020 Oct 2 18:35 1995 usr/doc/copyright/ae
drwxr-xr-x root/root 0 Oct 2 18:35 1995 usr/doc/ae/
-rw-r--r-- root/root 1147 Oct 2 18:35 1995
-rw-r--r-- root/root 5883 Oct 2 18:35 1995 usr/doc/ae/ae.man.gz
tar: Skipping to next file header
gzip: stdin: invalid compressed data--crc error
dpkg-deb: subprocess gzip -dc returned error exit status 1
-------------------------- unquote -------------------------
So, unless an explicit `gzip -t' does any better than this, I don't
see how doing it the other way around would do any better
i.t.o. providing safeguards against file corruption -- and I suspect
the effect might in fact be the opposite.
<email@example.com> |- "5. Improve constantly and forever the system of
production and service, to improve quality and productivity, and thus
constantly decrease costs." (W. Edwards Deming)