Hi,
>>"Charles" == Charles Briscoe-Smith <[EMAIL PROTECTED]> writes:
Charles> The tools to exploit this information aren't here yet, but I
Charles> -have- put a fair amount of thought into it, and I'm
Charles> convinced that this is data which a future tool could make
Charles> very good use of.
Impleent first, design later only leads one into a strait
jacket with very limited available courses of action. As I said
before:
Manoj> Until we have a tool, I do not think we can determine the input
Manoj> format for such a tool. Packaging files that could possibly be
Manoj> the input for an as yet unwritten tool (we are not clairvoyant,
Manoj> are we now?) is slightly silly.
Charles> If you disagree, I'd like to hear why.
I agree that these files are small. I also agree that for the
largest of our packages (the examples quoted were for the two largest
packages: xbooks[16862M <==> 25.32sec] and picon-usenix
[13428M <==>1min6sec]), these take a possibly unacceptable amount of
time. [1]. Note that these are probably the upper limit of the
elasped time we shall see.
However, for most packages, a simple command line invocation
displays the data on the fly. And compactness is not really a good
argument for inclusion.
>>"aph" == A. P. Harris <[EMAIL PROTECTED]> writes:
aph> It's a fundamental tenet in data quality analysis that data *use*
aph> should drive data collection, not vice versa. So until we really
aph> find how we need this file, how we use it, we shouldn't bother
aph> collecting the data.
>>"Mark" == [EMAIL PROTECTED] (Mark W. Eichin) writes:
Mark> Supplying an unspecified set of data in a random set of debs
Mark> doesn't particularly help anyone -- if deity or whoever comes up
Mark> with a useful tool, they'll *also* have much better information
Mark> on what data they want, and odds are that the current du output
Mark> isn't *quite* it... and thus we will have another compatibility
Mark> issue. If we simply leave them out now, we don't have to deal
Mark> with them until there *is* a use; and the idea Guy mentioned (of
Mark> putting this all up on the web site) does *not* particularly
Mark> need coordinated work.
Mark> In fact, a simple "how much space will this debian install take"
Mark> could be done as a cgi or javafrob, where the user selects
Mark> packages and cooks up a result based on a dump like that (hmm,
Mark> similar to the way Packages files are built perhaps.)
I think that is my technical reason for excluding this at the
moment. If you write a dpkg-check size method, I'd be the first to
ask for ratification of the format then used and making it a standard
part of debian.
manoj
[1] personally, if I am kept informed of the task, I would not mind
the time elapsed doing this on the fly
--- examining package blah (12 out of 33 package) 0:3:45 ---
--- / 10M /usr 33M /var 2M /usr/src 9M ---
actually look kinda neat.
I think the people claiming this is too long to be done on the
fly have not yet made their case. Do you know how long it takes to
install Digital UNIX, HP-UX, and NT on machines?
--
"All these black people are screwing up my democracy." Ian Smith
Manoj Srivastava <[EMAIL PROTECTED]> <http://www.datasync.com/%7Esrivasta/>
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
