[LONG MESSAGE] Re: `du' control files
In article <[🔎] Pine.LNX.3.96.980213112824.12555P-100000@monet>,
Christian Schwarz <schwarz@monet.m.isar.de> wrote:
>With the new lintian check I discovered that some packages install a `du'
>control file (contains the output of the du command).
Since I am the fool who introduced the `du' control file in the first
place, maybe I should explain why I did it...
Last summer, I was working for my PhD sponsors, and got the chance
to hang over my supervisor's shoulder while he upgraded some package
on the lab's Netra. This involved installing a package using SUN's
packaging system. This in itself was interesting, as the Netra comes
with no local graphics capability by default, and all administration is
done using a web browser. Apparently the admin system runs on port 81,
and many sites leave the default administration password in place...!
(Also, it seems that the Netra has sufficient problems that it is not
feasible to use it in headless mode. These people had canibalised
the machine the Netra replaced, and put its graphics board into the
new box and attached its monitor and keyboard, because they found they
needed to observe the console logs and tweak things via the console...
But back to the plot.)
The feature I was somewhat impressed by was that, despite a large
number of filesytems mounted in unlikely places, and symlinks pointing
to directories all over the place, the package management system was
still able to detail exactly how much space would be needed on each
filesystem as soon as the package was selected. I thought it would be
useful for a future Debian package manager (Deity, perhaps) to be able
to do the same thing.
The only way I could think of to achieve this was a simple copy of
the output of `du' run over the filesystem archive. With the usual
20/20 hindsight, it might not have been such a good idea to put it in a
separate file, since it is usually so small; it might be better to add
it as a new field into the control file, so it can be added into the
Packages file (the downside being that the Packages file immediately
grows by approximately another fifth of its size). Alternatively, it
could be discarded after installation, since it would, by that time,
have served its purpose.
I also decided that it was a good idea for conffiles to be excluded from
the md5sums file, and promptly wrote dpkg-geninfo to create these two,
and filed it in the bug system as a wishlist bug against dpkg-dev (see bug
#13220). I also contacted Joey Hess and suggested he put it in debhelper.
He adapted it into dh_md5sum and dh_du, and people started using it.
I appologise for doing this in what might seem a rather subversive
manner, without any public discussion; I agree that we should have the
discussion now.
I think that the `du' output is the most compact way in which we can
provide enough data for a package-installing front-end to work out in
advance whether there will be enough space to install a package, even
when there are lots of mounts and symlinks in the filesystem.
I seem to remember that there was a proposal that the installer should
just assume that everything will install onto /usr and do its space
calculations on the basis of that and the "Installed-Size" field in
the control file. I think this is far too crude. Given that such a
small amount of data (about 200 highly compressible bytes per package)
can give a far more accurate result, we should use the `du' method.
Christian continued:
>Does someone know which program is using these files??
As far as I know, no programs are using these YET. If we decide to keep
them, though, they will be useful for a FUTURE package manager.
>If there is no good reason for these files, should we consider this a bug?
>(IMO, yes.)
They are an experimental feature, like the md5sums files. We have no
policy against md5sums files, do we? So leave them for the moment.
Thanks,
--
Charles Briscoe-Smith
White pages entry, with PGP key: <URL:http://alethea.ukc.ac.uk/wp?95cpb4>
PGP public keyprint: 74 68 AB 2E 1C 60 22 94 B8 21 2D 01 DE 66 13 E2
Reply to: