Subject: Re: PROPOSAL: NetBSD System Packages (LONG)
To: Robert V. Baron <rvb@cs.cmu.edu>
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
List: tech-install
Date: 10/01/1998 14:40:04
First, disk space is _an_ issue but its not the over-riding one.
Assertions about what are and aren't install-tool issues coming from
non-install people should be taken with a grain of salt.
>Is all this concern about space warranted? [snip lots]
Rob, I understand the arguments you made, they're good ones. But only
if you have a new emachine or a machine that can handle new, cheap IDE
or SCSI disks. They dont just hold for a microvax-2, or an SMD sun3,
or maybe even an MFM i386 (compared to the price of one.)
the price of a SCSI adaptor for these systems is comparable to the
cost of a complete new Pentium-II system-- if you cn even find one.
>I have the standard old
>sets and x loaded into about 200meg. (This is for an x86 platform.)
People do try and install NetBSD onto 80s and 90s systems which still
have their late-80s/early 90s disks: ~200M or so. One well-known
developer comments from time to time about how NetBSD used to install
onto a 386 with 4M ram and 80M disk, and why can't we support upgrades
of machines like that? ANd just today I got a message from someone
who didn't install X on a pmax becuase it wouldnt fit on his 200M
disk, and we dont have very good support for adding multiple disks in
at install time.
So. Disk space crunch is _one_ of the drivers for pkg-izing the
install sets. That's a fact, even if its not applicable ot your setup.
Given that, checking for space is a reasonable thing to do if we can
do it easily, surely? Especially given how nastily things go wrong if
you run out of space during an install?
>On the otherhand, I'm really interested in the new proposal because
>I want to be able to reinstall an old package that I've broken, or a
>newer version of the egcs package or do sane upgrades, ...
Yes, thats another nice feature of pkg-izing the sets. obviously
disk-size checks is not important there, but it is for other uses of
pkg-ized sets.
>Also, anyone give thought to making the md5's a first class citizen of
>packages so I can ask pkg_info to verify the installed base against
>the official md5's in the package (ala FreeBSD mtree).
Please take that up with the pkg people. pkg-ized install tools will
just be using the normal pkg tools to install the pkgs in pkg-ized sets.
But yes, I think we should support something more tripwire-like.