-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

These are the notes which came out of the original discussion of NetBSD
system packages.  Some points here are a little dated, I will update
this later this week:

- ------------------------------------------------------------------------
I have been spending a lot of time lately thinking about how we
can extend our current package system to allow the use of system
packages (and sets thereof) rather than tarballs as our primary
way of installing NetBSD systems.  What follows is a random jumble
of thoughts on where we can go with this.  Based on people's response
to this, I will put together a more concrete proposal soon.

1. Package Granularity

    People would like to be able to install/remove system software
    with a high level of granularity.  (Do I want Kerberos, but
    not UUCP?  C but not Fortran?  Text formatting but not printing?)
    This could be best addressed by providing our system software
    as a series of packages which could be installed individually.
    Dependencies would then exist among these packages, which would
    insure that a working system resulted from various combinations
    users might choose.  For example, users could choose a C package
    and/or a Fortran package, and both would depend on a binutils
    package.

    At the same time, users should not need to choose between a
    thousand little packages when installing the system.

    This probably means that there should be the concept of `sets'
    of packages to be installed all at once, roughly analogous to
    our current breakdown into base, comp, etc, games and so on.
    A set would contain a number of packages, and a contents file
    indicating which packages were part of the set.  An install
    program could then default to let users pick among whole sets,
    but could have an advanced mode which would let users pick
    individual packages instead.

    Very possibly, this would open the possibility of keeping set,
    information, in addition to package information around, and
    offering the ability to remove all installed packages from a
    given set at a later date.

    Alternately, a system similar to our existing pkg-src/meta-pkgs
    mechanism could be used -- users would choose meta-pkgs more
    or less equivalent to the current sets, and these would trigger
    dependencies on the packages which make up the set.

2. Package Registration

    Currently, packages are installed in /usr/pkg and /usr/X11R6,
    and all package registration is done by creating directories
    in /var/db/pkg.

    This is generally agreed to have a couple of problems, especially
    when you want to share /usr/pkg between multiple machines.
    Unless /var/db/pkg is the same on both machines, you very
    quickly end up with at least one machine not knowing what
    packages it has installed.

    Alistair Crooks has recently put together changes to use
    ${LOCALBASE}/etc/pkg and ${X11BASE}/etc/pkg to store package
    registration information, which is a big step toward solving
    this problem (yahoo!).  Presumably, system packages will use
    /etc/pkg, although this leaves open the question of what to do
    if you share /usr between multiple client machines.

3. Package Creation

    Right now, the Makefile in .../src/etc can be used to build
    distribution sets, which are tarballs to be unpacked relative
    to / by the installer.  Sets are defined by lists in
    .../src/distrib/sets/lists, and consist of MI and MD components.
    Thus, where sources are installed in /usr/src,
    /usr/src/distrib/sets/lists/comp/mi contains a list of files
    in the compiler set which are available on all architectures,
    while /usr/src/distrib/sets/lists/comp/md.i386 contains a list
    of those files which are on the i386, but not on all other
    architectures.  All shared libraries, for example, are in the
    md set, since not all ports have shared libraries.

    In order to move to using system packages, we will need to
    provide a way to generate binary packages from our source tree.
    It should be noted that the granularity of packages does not
    really match the granularity of source subdirectories in
    /usr/src/*, so barring a source tree re-organization (which
    seems undesirable), we will need a way to do this which (like
    the current mechanism) is outside of the normal `make clean ;
    make depend; make' recursion through the source tree.  A system
    will also be needed to allow building a set out of a group of
    packages.  Both of these systems will need to be simple to use
    (one make command line), and should be possible to run on a
    single-package or single-set level.

4. Package Versioning and Upgrades

    One of the neatest features offered by having independent
    packages for different parts of the system is the ability to
    upgrade a single package independently of the whole system.
    Although this should not be abused (we don't want to become
    like Linux where on an average system nothing quite matches
    anything else), it would provide an ideal way to distribute
    important patches and security fixes.

    For example, the security patch for NetBSD-SA1998-004 (at(1)
    being usable to view any file) was distributed as a patch to
    the NetBSD-1.3.2 source tree.  This requires anyone who wishes
    to install the fix to have a source tree available, download
    and apply the patch, and then rebuild at(1).

    In a system based on install systems, an updated version of
    the specific package containing at(1) could be released, which
    users could download and pkg_add in a matter of moments.  It
    would also be easy for an admin to tell if a system had been
    upgraded by looking at pkg_info output.

$Id: NOTES,v 1.3 1998/09/18 21:43:09 jwise Exp $

- -- 
				Jim Wise
				jwise@draga.com


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

iQA/AwUBOIttCi2NgFbJL33VEQLdJACfSQaIGafPKIJ73otFSP676FJLq/kAoIzQ
Q7WbLcBHyZrRZRX6523QFGs4
=+wCf
-----END PGP SIGNATURE-----