[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug reporting script



richard@elmail.co.uk (Richard Kettlewell) said:

> Bill Mitchell writes:
> > [package overhead file with name:mode:md5sum:size of package files]
> I don't think that's right - all the information required is already
> in the package in the form of the files themselves; why duplicate it?
> If it's going to be anywhere it's much more sensible to generate it at
> install time.  There's no sense in bloating .deb files more than is
> necessary.

I argue that the info is useful.  If that point is granted, one question
which arises is whether to generate the info at package install time or
at package build time.  I'd argue for generating it at build time as a
size vs. time tradeoff to allow a fairly fast operation to extract the
pre-packaged info vs. a series of fairly slow operations per-package
to generate it on the fly.  Also, some of the info, size info in
particular, would likely be mose useful at package browse time while
the user is deciding whether he wants to unpack the packages.

I'm guessing that a package file with this info would be about double
the size of the current /var/lib/dpkg/info/<package>.list files.  For
the packages which I`ve currently got installed, those files average a
bit over 3K per package.  Compressed with gzip -9, they'd avarage a bit
over 500 bytes per package.  So, if the file is stored in the package in
compressed form (reasonable, I think), we'd be talking about adding an
average of about 1K per package.

> Your suggestion also has the disadvantage that every package in the
> distribution would need updating; whereas if the extra information is
> generated at install time, all current packages will just work.

I suggested that the package admin tool could recognize whether
packages contained this info or not, and handle them appropriately.
"Appropriately" might mean generating the info at install time
for packages which didn't contain it.  This would avoid a need
to update all packages at once for compatability, and would avoid
sacrificing backwards compatability with older packages.  The info
could be added as packages were rebuilt for other reasons using
the updated package admin tool, and there would probably be a
target date for all packages to be updated.


Reply to: