Re: On adding size info to Packages files [very long]
Manoj Srivastava <srivasta@datasync.com> writes:
> Hi,
> >>"Brederlow" == Brederlow <goswin.brederlow@student.uni-tuebingen.de> writes:
>
> Brederlow> Would that already be a correct Packages file or would dpkg and
> Brederlow> similar scream about wrong entries? Could old dpkg's handle the new
> Brederlow> entries?
>
> As I mentioned elsewhere, there is no reason for this to be
> included in the Packages file. The size estimation should be
> *OPTIONAL*, and people should not have to download all the data
> unless they want the estimate.
That was more a question of would and not of should. Would it be a
correct Package file with something like that (or similar) in it, or
would it be rejected by dpkg?
> Moerever, the available file (and the status file) are created
> from the Packages files, and there is no reason to bloat them further
> with duplicated information, and further increase the startup time
> for programs that rread them and cache them in memory.
>
> Brederlow> Lets trimm those to reasonable size. Directories that are
> Brederlow> package intern will hardly be on separate
> Brederlow> partition.
>
> I see little reason to go through these hueristics; I prefer
> the original proposal of creating separate files based on the depth;
> however, the raw data is there for people who want it.
Some Packages have a big du tree with very deep directory levels. Each
directory contains only a few blocks. It should be save to assume that
directories that are package intern and are less than n blocks (n
small, say 100 or 50) won't be on seperate partitions. The work to do
to link (or mount) those directories elsewhere is just not worth the
gain (of max 100K), so it won't be done. (And if its a matter of 100K
being somewhere else, the person should kick the du index all together
to save another 100K).
> Brederlow> Theres another possibility: Normal users wont backup their
> Brederlow> System, repartition differently and restore the backup (at
> Brederlow> least not often). Also they wont move directories around
> Brederlow> and link them often. We could thus trimm the du tree down
> Brederlow> to what the current system reflects.
>
> Huh? what does the current system reflect? For whose machine?
> Oh, you mean everytime we download the data, we spend time mucking
> around with it and trimming it down? I think that would be very
> prohibitive on slower machines, especially since the data is only
> useful for a short time. A better approach is to download the proper
> sized size file (If all my partitions are at the top level or at the
> second level, like /usr/lib; I just download Size.2.gz; and never do
> local processing on the data).
I mean, that when a package is installed, that the recorded du tree
(which is needed to calculate the size increase/decrease for updates)
could be trimmed to what the users system reflects. The users system
setup should be scanned and kept in a status file for speed reasons
(trying all dirs for symlinks takes time) and then trimming should be
fairly easy and save a lot of space. It would save the more the smaler
(less partitions) the system is.
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: