Re: Sizes and Packages in dselect
Raul Miller writes ("Re: Sizes and Packages in dselect"):
> Ian Jackson:
> This is where the problem starts :-). Obviously this can be done
> fairly easily if you're willing to have the user download a list of
> all the files included in every package, plus their sizes. I don't
> think that's reasonable, though; even compressed, the Contents file
> for just the main part of the distribution is 120Kb.
>
> On the other hand, it shouldn't be too hard to modify dpkg-deb to
> compute summary information for each directory which is being
> packaged. (number of blocks, number of inodes directly in each
> directory). For packages which have some significant postinst
> overhead, these estimates could be put in some file in the DEBIAN/
> directory for the package.
Yes, but where would that get you ? When the user is initially
selecting packages all that dselect has seen is the Packages file -
this file is only 30K compressed.
The problem isn't extracting the information from .deb files.
There are two main problems: firstly, the information about sizes has
to be given to dselect somehow, and this has to be done *without*
processing all of the .deb files before the package selection takes
place. Secondly, doing per-filesystem accounting may well produce
complicated and probably-incorrect code in dselect.
Set against this, I don't think many people will use this feature.
Almost all of the stuff that you might choose whether to install lives
in /usr somewhere, and few people subpartition /usr (I'm not counting
/usr/local, here). Those that do will be experts who will be aware of
things like the relative sizes of /usr/lib and the rest of /usr.
> I don't think the storage requirements for this kind of information
> would be at all outrageous:
It's not the storage, it's the transmission. For someone who is
downloading the distribution onto floppies an extra 120K file is
rather on the large side, considering that they'll probably never use
the extra functionality it buys the system.
> Besides, the packing problem is a hard one to deal with -- so it's
> very worthy of whatever automatic assistance we can provide.
I'm confused. Which packing problem is this ? I don't think the
decision about how to partition your disk is difficult: if you're
having trouble with it, make one big partition - this is fine for most
users, now that our fsck tools are as good as they are.
Do you refer to the problem of how to pack .deb files onto floppies,
if that's what you're doing ? In that case I agree with you, but I
don't see how that's relevant to the question at hand.
Bill Mitchell writes ("Re: Sizes and Packages in dselect "):
> [...]
> The packages I have in the base directory total 3619624 bytes.
> "dpkg --contents" gives a bit more verbose of a list than would
> be needed for sizing. "dpkg --contents" on all these packages,
> putting the output into separate files, produces a total of 213503
> bytes of data. "gzip -9" on all those output files reduces that
> to 25172 bytes of data. That's about 0.7% additional overhead.
If you look at the size of the whole main distribution, about 80Mb,
the Contents file (which compresses very well) is about 1.5%.
However, what you're forgetting there is that the user will have to
download the whole file even if they only want to install a small
subset of the packages.
I'd be interested to see someone find out how large a file is that
lists disk use per directory for each package. Ie, something like
hello:
3 /usr/doc/copyright
8 /usr/bin
9 /usr/info
but for each package. (The numbers are Kb, rounded up.) If this
turns out to be a reasonable size then we could have a Size field in
the Packages file that contained this information. (If we do
mkpackages right then we can have package maintainers override this
information simply by providing a Size field of the right form.)
> > I think it's probably better just to stick a single `Size' field in
> > the Packages file.
>
> Which wouldn't help in sizing per-partition usage.
That's right. How many people have needed to do this ? Disks
nowadays are so big that subdividing the /usr partition doesn't have
much point, and the usages on /, /var and /home are (a) small and (b)
very dependent on the local situation.
Ian.
Reply to: