Subject: Re: AFS/arla
To: Jim Wise <email@example.com>
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
Date: 09/17/1998 13:37:21
>>Actually, I've been advocating that for some time now :-)
Jason isnt the only one...
>If this is generally thought to be a Good Thing, I would be willing to
>take on doing a pkg-ification of -current's install stuff... At least
>to do an interface spec and a first stab, so we can see what goes
We thrashed out a lot of the isssues re: pkg-izing binary
distributions once before. There were a lot of conflicting
requirements and opinions about:
* the large granularity of what now gets installed from
individual sets like ``base'' (people who dont want UUCP, ...)
* strong opposition to forcing everyone to choose
whether or not to install dozens of fine-grained pkgs
(common case is to install everything)
* Bloating the install media for popular platforms beyond one
floppy, since we need pkg_install tools to unpack
stuff rather than just tar for .tgz files
* Granularity of packaging the sets
(how many tarfiles do you have to suck down from an FTP
site, and then check you've got them all?)
The consensus back then was a hierarchy, with `set' files containing
* Partition at least `base' into individual pkgs
at the rough granularity of, say, "uucp" or "rcs",
or "normal" vs "profiled" libraries.
* Ship sets as one .tgz file containing a .tgz pkg file
for each `package' in that set.
* Allow users to choose to install everything, or select
individual sets, as we do now.
Plus for set-by-set, an `expert' option to select individual pkgs
within each set, (so an expert can tailor an install for,
say, a 4Mb RAM/80MB disk i386)
* the `tailored install' menu was sposed to be generated from a
CONTENTS-like file in each set, not hardcoded into sysinst.
I think menuc can now do scrolling menus, I dont know about
runtime-generated contents, though.
The set-as-tarball-of-pkgs change is fairly simple, if you punt for
now on the UI changes. Mostly sh-script hacking to build the sets,
and then using the existing parse-and-loop machinery in sysinst to run
pkg_install over a `CONTENTS'-like file, rather than untarring each
tarball directly into the target.
You might handle the bootstrap problem by a `boot-base' tarball in the
base set, which includes the pkg tools, plus pre-generated pkg
database info for the contents of `boot-base'.
Oh yeah, the other thing people suggested was tweaking the sysinst
menu hierarchy, so you an use sysinst as the UI to install pkgs on a
live system after `system installation'.
More than you intended, maybe, but adding `system' pkgs for AFS or
coda or whatever would drop out `for free' as just another
pkg-in-tarball config-file, and another menu entry for the new set.