Subject: Re: PROPOSAL: NetBSD System Packages
To: Hubert Feyrer <firstname.lastname@example.org>
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
Date: 09/30/1998 15:48:30
[again, I'm trying to cc: tech-install on anything that overlaps
wiht instal/sysinst issues]
Hubert, this very same proposal has been beaten to death and beyond
once before but from the install side.
The consenus then was that it's important to be able to get the entire
"base OS" distribution as a reasonable number of files. There are
several good reasons for this, not least for people who are trying to
pull install materials off the net, and pre-laod them to local media
before installing (e.g., an ms-dos partition) or to load them before
going to a remote site (or to help a friend install).
This came up when we designed release(7). If you want to argue for a
rethink of the constraints behind the structore of
release/binary/sets, argue with Core. (NB I'm assuming the move from
.tgz to pkgset is okay with Core!)
For the rest, I go with Jim Wise' answer.
Once you accept the requirement for pkgsets with the same granularity
as our existing sets, acually containing copies of the constituent
packages rather than pointers to them, then all the questions pretty
much fall into place as Jim has anwered them.
I'd replace the existing makeset / makeflist/checkflist with a new
"makeset" script which makes pkgsets instead of tarballs. The makeset
arguments would not change. The sets/lists directories would be
replaced with, say, a directory tree, one dir per pkg in a set.
Each directory would have partial PLIST files for:
* object-fmt dependnet
plus a script to create the PLISTS and check the contents exist in
$DESTDIR. We'd compute the sizes of each pkg when the pkg is built.
At set-creation time we'd, add installed-size of all pkgs in a set to
get the installed size of the whole set.
I hope we've reached consensus on that much.
I'm afraid I dont understand why you make a distinction bewteen
+CONTENTS and +SIZE. What's the difference? Is one available via FTP
separately from the actual pkg file? If it is, we can make the
+SIZE available too.
If not, what _is_ the difference? If there's a special frob to FTP a
pkg to stdout and snarf out the first file from the stream (and then
close it without waiting for the rest), then we can mandate that +SIZE
is the secnd file and do another frob to sarnf out the _second_ file,
too. I genuinely don't get it. would you mind explaining, please?