Simon Burge writes:

>On Wed, 30 Sep 1998 00:23:56 -0400 (EDT)  Jim Wise wrote:

>> On Wed, 30 Sep 1998, Simon Burge wrote:
[snip[

>> I think the set contents file should only contain information that can
>> be automagically gathered from each package's pkg/* files...
>
>I think I disagree with you here.  From a sysinst point of view, I'd say
>we need to know the total installed size of each package, and that isn't
>available in the pkg/* files.
>
>In an ideal world, I want to tell sysinst that I want packages A, B, C
>and so on, on a disk with separate / (with 30% free space), /var (64MB
>in size), /usr (with 50% free space) and the rest of the disk in /data,
>and come back however long later with a full system.  Shorter term, just
>selecting the packages you want and sysinst telling you how big your
>desired partition layout is (with a granularity of /, /usr and /var) and
>manually filling in the partition sizes is a definite goal.

I think I agree with Simon here, but for different reasons.

Jim, the way I see it, the key thing is to nail down the pkg-set
format, get out a prototype, and then let people add frills.  There's
a vast set of frills, most of them are UI issues, or UI plus
recording-of-what-was-done-last time that're incidental to the real
essential issues of the pkg-set format and building even rudimentary
tools to replace the current sets.

Here's what I'd do:


     i) Nail down the format of the pkg-set file,
        esp. whether it includes size info;

     ii) implement support for that
        a) build tools for port-master/snapshot-builder types  like
           Perry to build the new-format pkg-sets.

	   This probably means adding support for arch- and toolchain-
	   specific files to  the tools that acutally build pkgs.,

        b) decide how to carve up the existing sets into  pkgs.
	   For now, you can just about do  whatever seems right to you,
	   and we can thrash out the fine points later.

	    then carving up distrib/sets/lists/* into pkg lists.

        c) rework the set-untar subroutines in sysinst to look for,
	   and deal with, pkg-sets. itd be nice if we could handle both
           the old sets and pkg-sets for awhile, but not necessary.

	   A  0th-pass could just parse the contents of a set-pkg
	   and install all the component pkgs, with stubs to select
	   pkg-by-pkg later.	   

Then let Perry and me and whoever build snapshots, let people
experiment with them, and add the frills that're necessary --
`tailored' (pkg-by-pkg) installs, or (to push Simon's idea further) a
GUI-slider-like tool to adjust sizes of BSD-label partitions during
install (perhaps checked against the unpacked size from the sets/) or
kre's no-overwrite flags; prefixes to never ever install under;
automagic NFS-mountpoint exclusion.  Whatever.


Once we do the tarball-set to pkg-set cutover, all the frills come
down to UI design, deciding how and when to recall previous options,
re-working the paritioning of sets into pkgs, and a SMOP.  Those _are_
important, but IMHO we shouldnt let them take precedence over the
nuts-and-bolts of replacing one install-set format (and tools to
produce them and install them) with one that allows us to actually
implement whatever frills we agree on.  Whether the frills end up in
(standalone) sysinst, in an expanded sysinst, or even an X-based
replacement/enhancement.


Oh yes, and I think it's very important to let a naive user do a
typical first-time install without even being aware of exactly what
frills we have, let alone choosing amongst them.

Plus, this has the advantage that when someone suggests new or
improved frills, or a whole new UI, you can point them at the basic
pkg-set machinery and say ``go right ahead'' :->.