Subject: Re: PROPOSAL: NetBSD System Packages (LONG)
To: Hubert Feyrer <feyrer@rfhs8012.fh-regensburg.de>
From: Jim Wise <jwise@unicast.com>
List: tech-install
Date: 10/02/1998 11:49:31
-----BEGIN PGP SIGNED MESSAGE-----

[ Alistair -- I agree that we should stop banging our heads against this
  one for a while, but I think it's important that we at least reach the
  point of agreeing on what we are disagreeing about first. ]

On Fri, 2 Oct 1998, Hubert Feyrer wrote:

>Well, decide - do you want pkg upgrading, or do you want this
>pkgset/container stuff? Pkg upgrading is on our todo-list (after fixing
>the whole pkgsrc tree do use wildcard depends properly). 

I really don't understand this one.  Aside from taking another chance to
let us all know that you don't want package sets, are you saying that
package sets and package upgrading are in conflict?

This doesn't make sense.  System packages will be standard packages.
They will benefit from package upgrading if and when the package tools
support this.  Package sets are orthogonal to this -- they simply
provide a container for normal packages.  It would be wonderful if the 
requirements for package sets could be met by extending the package
tools slightly.  Both Jonathan and myself have repeatedly asked for the
guidance of the pkg-people in achieving this (you are our experts in
these tools, after all).  All I have seen from you in response is
arguments that the basic requirements for installation sets be thrown
away if they are not easily met with today's package tools.

There is a basic set of requirements for the distribution format for
NetBSD.  Whatever tools we use to create and to install distribution
files need to meet these requirements.  This is true whether these files
are packages as we know them now, packages with some extensions, or an
entirely new format.  I don't claim to be any sort of expert in the
design on such a format, and although I have seen several excellent
suggestions float by for how this can be done, I would be happiest if we
could achieve these requirements in a way that was blessed (or even
designed) by the pkg people.  This way, the same tools could be used
with packages and sets, which would make everyone's life easier.

The basic requirements are this:

	1.) Users should be able to download a small number of
	    distribution files to use in installing NetBSD.  It should
	    not be assumed that they already have access to a NetBSD
	    system with NetBSD package tools before they can get the
	    files needed to install NetBSD, nor is it fair to assume
	    that they will have network access at install time.

	2.) Sets should mirror the functionality of today's install
	    sets -- they should be able to be built automatically
	    from a minimum of static data (ideally just a list of
	    enclosed packages), and should have a `make distrib'
	    capability similar to what we provide now.

Both of these capabilities are provided by the current install sets, and
it is not reasonable to give them up.  Both of these requirements were
reached after long debate back at the time that release(7) was designed,
and barring a decision from core that they are no longer necessary, I
consider them non-negotiable.

Two other requirements follow naturally from having sets be made up of
packages instead of individual files.

	3.) At install time, users should have a choice between
	    installing an entire set or choosing individual packages
	    from that set to install.

	4.) Having installed the system, it should be possible to
	    cleanly add, remove, or upgrade individual components
	    of the system, again at a package or set granularity.

These are negotiable, but without them I don't see much point in going
through the work to pkg-ize our install process.

- -- 
				Jim Wise
				jwise@unicast.com

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 5.0i for non-commercial use
Charset: noconv

iQEVAwUBNhT2EYkLDoBfn5jPAQEvOAf/fJ8Kkqp2+SIBFa1b6dBbcHByM2fqk75U
njQlCmC7kIKFes/CNfZvtTHhA8Uml7v+x6ISWQaHe6cYv62HWit7jpflmEQH1H3G
46UAmzsVmieuUoZs6S22Gta10aw5HZxUIjdJ9VtZ6+jSWMLhRuivjFWR+ye+yGSd
RGpJNwcBJMn+Bbrpwh/7M9sT48tZu1qChd7Xb+orLTpPF637giu83W6uPMFinOhh
9GklOQVPYreothJoI+CSf2qZn5Qd5Ss+lU+Mxal4N6LxAtts9WOn876F0npZTw6O
sE1Mv9pvJs4GXiO7rNuK6+PrNhzNIBcJNlpbSsuNEQsDlN+wMCDTrg==
=rftx
-----END PGP SIGNATURE-----