Ian Jackson said:
> From chuck Tue Oct 3 22:02:24 1995
> Return-Path: <chuck>
> Received: by bertha.richnet.net
> id <[EMAIL PROTECTED]>
> (Debian /\oo/\ Smail3.1.29.1 #29.33); Tue, 3 Oct 95 22:02 EDT
> Resent-Sender: chuck (Charles A. Stickelman)
> X-POP3-Rcpt: [EMAIL PROTECTED]
> Received: from mongo.pixar.com (mongo.pixar.com [138.72.50.60]) by
> ns1.richnet.net (8.6.12/8.6.12) with SMTP id VAA11211 for <[EMAIL
> PROTECTED]>; Tue, 3 Oct 1995 21:35:12 -0400
> Resent-Date: Tue, 3 Oct 1995 21:35:12 -0400
> Received: by mongo.pixar.com (Smail3.1.28.1 #15)
> id m0t0IiA-000D7iC; Tue, 3 Oct 95 18:33 PDT
> Old-Return-Path: <[EMAIL PROTECTED]>
> Message-Id: <[EMAIL PROTECTED]>
> Date: Wed, 4 Oct 95 02:31 BST
> From: Ian Jackson <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: Re: Sizes and Packages in dselect
> In-Reply-To: <[EMAIL PROTECTED]>
> References: <[EMAIL PROTECTED]>
> <[EMAIL PROTECTED]>
> Resent-Message-ID: <"vUNHY.A.MFE.oRecw"@mongo>
> Resent-From: [EMAIL PROTECTED]
> X-Mailing-List: <[EMAIL PROTECTED]> archive/latest/6456
> X-Loop: [EMAIL PROTECTED]
> Precedence: list
> Resent-Sender: [EMAIL PROTECTED]
>
> Bruce Perens writes ("Re: Sizes and Packages in dselect "):
> > I think I have the algorithm to do this. Please see if the following makes
> > sense. I can give you pseudocode (or real code) if necessary.
> >
> > For each file in the files list, find the deepest existing directory
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> 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.
>
> > Does this make sense? I can elaborate if you like.
>
> Yes, your algorithm probably makes sense (I didn't read it in great
> detail). However, the problem isn't the algorith, I think, but the
> question of how to get the data it needs to dselect.
>
> I think it's probably better just to stick a single `Size' field in
> the Packages file.
>
Maybe we should do both. Include file sizes in the .list files, use
Bruce's algorithm (or something like that) to compute the 'Size'
field in the Packages file. That way the users could get the information
initially when they grab the Packages file and a running system could
use the .list files to get more system-specific information.
It may not be necessary for dselect/dpkg to function identically
identically during install as they do on a running system. If the
user is doing a "vanilla" Debian install (whatever that may be)
just show the 'Size' values. If they are doing a more complicated
install with multiple partitions (networking or whatever) then why
not allow them to use this level of detailed information?
I'm an advocate of adding more information to the .list files
(user/group, mode, size, md5sum and perhaps hard-link info, etc.)
even if it forces us to use data-compression.
> Ian.
>
>
Chuck
--
Charles A. Stickelman <[EMAIL PROTECTED]>
Practical Network Design (419) 529-3841
9 Chambers Road
Mansfield, OH 44906 USA
--
