Re: Bug reporting script
On Tue, 15 Aug 1995, Richard Kettlewell wrote:
> Bill Mitchell writes:
>
> >Yeah. I had other uses for some of that info besides audit in the
> >back of my mind.
>
> Perhaps it would help the discussion if we knew something about them?
Sizes would be useful for helping users install packages. Actually,
a long time ago I suggested that package selection might be done
prior to disk partitioning so installers could have some idea of
how much space they'd need in the various partitions -- with the
selection list being saved for later reference at package install
time. That suggestion died a fairly quick death, but it'd still
be useful to know if users have selected packages which will
overflow the disk capacity they've got to hold them. Sizing
info at least per-directory from the packages would be needed to
do that. It's probably not useful once the packages are installed,
so needn't go in the .list file.
md5sum was playing on the theme of file-granularity awareness in
the package admin tool, and would allow the package admin tool to
detect an attempt to remove or overwrite a package file which
no longer matches the file which was installed. We revisited that
topic here recently, but the discussion petered out without
coming to any real conclusions.
One thing did come out of that recent discussion which would reduce
the utility of this -- a hint of a hard-line position that debian
users are expected to not install files in certain directories
which we'll consider to be debian's "turf". This hasn't been well
articulated, but my sense is that the debian user is expected to
stay out of /usr, /bin, /sbin, /lib, and perhaps /etc. Making it
clearly articulated policy that users are not allowed to install
files in these directories, which might collide with package files,
would remove a need I'd seen to detect such collisions and handle
them in a reasonable manner. (That is, if a user installs a file
where he shouldn't, he shouldn't be suprised if we trash it).
Leaving out detecting and handling collisions from trespassers
onto debian's filesystem "turf", that leaves detecting per-file
collisions between packages as the only reason for per-file
md5sum info. That too was discussed here recently, and the
discussion petered out with no real conclusions having been
reached.
What it comes down to for me is that I see per-directory sizes
and per-file checksums or md5sums as potentially useful, along
with the filemode, user, and group info you (I think) mentioned.
This info won't change between package build time and package
install time, and the overhead to generate a list of this info
is better taken once at package build time than every time a
package is installed. I also see carrying this info around in
a package, particularly if it's compressed, as such a tiny
increase in package size as not to make a difference. Whether
the package admin tool chooses to use this info, or to save
it online for later reference, is another matter.
> [...] md5sum can be stored in 16 bytes, of course; and one can't really
> compress it beyond this. (I should have done the previous experiment
> with this in mind, in fact. Silly me.) MD5 may be overkill, a CRC
> might be OK for recording signatures of all the files in a package.
I recall a tirade about sum(1) being "completely useless", and
md5sum being the only signature program to use when I suggested
this a few months back.
Reply to: