In article <[EMAIL PROTECTED]>, Christian Schwarz <[EMAIL PROTECTED]> 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
