Re: New APT version
Manoj Srivastava <srivasta@datasync.com> writes:
> Hi,
> >>"Jason" == Jason Gunthorpe <jgg@gpu.srv.ualberta.ca> writes:
>
> Jason> How do you intend to get the information? Examine the debs
> Jason> after they are downloaded?
>
> Well, I think that putting the information into the Packages
> file is a bad idea -- especially for large packages. We need a line
> per directory and there is no reason to inflate the packages files
> for packages we ain't even updating.
>
> So, yes, I was thinking of taking the .deb apart using ar and
> looking at the sizes file; yes, it is slow, but I guess you can
> either have ample disk space, or suffer while apt figures out whether
> you have enough space left; so everyone else is only minimally
> impacted ( a small one block file embedded in the .deb for most
> packages).
Generating an du index of a package dees unpacking this package.
Now you have two choises:
1) tar -tzvvf | count_size_for_partitions/generate_du_output
2) tar -xf && du
The first makes installing Packages much slower (half speed), the
second needs enough space for the complete Package somewhere.
Both methods are inaceptable for general use.
I think a good way to include du information would be to only include
size information for directories that are not formed by the Package
itself.
for XFree its enough to know the size of
/usr/X11R6/lib
information for /usr/X11R6/lib/X11 would be overhead.
Because its hard (a lot of work) to tell what directories will on
different devices and which will never be on different devices, its
probably a good idea to include a du tree for say the first 3
directory levels /usr/X11R6/lib but not further. 4 or 5 might be a
saver value, but that could be made the reponsibility of the
maintainer. Theres no need to define that it must be 3. Any depth
should be handled correctly.
May the Source be with you.
Mrvn
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: