distrib/syspkg/notes/NOTES

   1 I have been spending a lot of time lately thinking about how we
   2 can extend our current package system to allow the use of system
   3 packages (and sets thereof) rather than tarballs as our primary
   4 way of installing NetBSD systems.  What follows is a random jumble
   5 of thoughts on where we can go with this.  Based on people's response
   6 to this, I will put together a more concrete proposal soon.
   7
   8 1. Package Granularity
   9
  10     People would like to be able to install/remove system software
  11     with a high level of granularity.  (Do I want Kerberos, but
  12     not UUCP?  C but not Fortran?  Text formatting but not printing?)
  13     This could be best addressed by providing our system software
  14     as a series of packages which could be installed individually.
  15     Dependencies would then exist among these packages, which would
  16     insure that a working system resulted from various combinations
  17     users might choose.  For example, users could choose a C package
  18     and/or a Fortran package, and both would depend on a binutils
  19     package.
  20
  21     At the same time, users should not need to choose between a
  22     thousand little packages when installing the system.
  23
  24     This probably means that there should be the concept of `sets'
  25     of packages to be installed all at once, roughly analogous to
  26     our current breakdown into base, comp, etc, games and so on.
  27     A set would contain a number of packages, and a contents file
  28     indicating which packages were part of the set.  An install
  29     program could then default to let users pick among whole sets,
  30     but could have an advanced mode which would let users pick
  31     individual packages instead.
  32
  33     Very possibly, this would open the possibility of keeping set,
  34     information, in addition to package information around, and
  35     offering the ability to remove all installed packages from a
  36     given set at a later date.
  37
  38     Alternately, a system similar to our existing pkg-src/meta-pkgs
  39     mechanism could be used -- users would choose meta-pkgs more
  40     or less equivalent to the current sets, and these would trigger
  41     dependencies on the packages which make up the set.
  42
  43 2. Package Registration
  44
  45     Currently, packages are installed in /usr/pkg and /usr/X11R6,
  46     and all package registration is done by creating directories
  47     in /var/db/pkg.
  48
  49     This is generally agreed to have a couple of problems, especially
  50     when you want to share /usr/pkg between multiple machines.
  51     Unless /var/db/pkg is the same on both machines, you very
  52     quickly end up with at least one machine not knowing what
  53     packages it has installed.
  54
  55     Alistair Crooks has recently put together changes to use
  56     ${LOCALBASE}/etc/pkg and ${X11BASE}/etc/pkg to store package
  57     registration information, which is a big step toward solving
  58     this problem (yahoo!).  Presumably, system packages will use
  59     /etc/pkg, although this leaves open the question of what to do
  60     if you share /usr between multiple client machines.
  61
  62 3. Package Creation
  63
  64     Right now, the Makefile in .../src/etc can be used to build
  65     distribution sets, which are tarballs to be unpacked relative
  66     to / by the installer.  Sets are defined by lists in
  67     .../src/distrib/sets/lists, and consist of MI and MD components.
  68     Thus, where sources are installed in /usr/src,
  69     /usr/src/distrib/sets/lists/comp/mi contains a list of files
  70     in the compiler set which are available on all architectures,
  71     while /usr/src/distrib/sets/lists/comp/md.i386 contains a list
  72     of those files which are on the i386, but not on all other
  73     architectures.  All shared libraries, for example, are in the
  74     md set, since not all ports have shared libraries.
  75
  76     In order to move to using system packages, we will need to
  77     provide a way to generate binary packages from our source tree.
  78     It should be noted that the granularity of packages does not
  79     really match the granularity of source subdirectories in
  80     /usr/src/*, so barring a source tree re-organization (which
  81     seems undesirable), we will need a way to do this which (like
  82     the current mechanism) is outside of the normal `make clean ;
  83     make depend; make' recursion through the source tree.  A system
  84     will also be needed to allow building a set out of a group of
  85     packages.  Both of these systems will need to be simple to use
  86     (one make command line), and should be possible to run on a
  87     single-package or single-set level.
  88
  89 4. Package Versioning and Upgrades
  90
  91     One of the neatest features offered by having independent
  92     packages for different parts of the system is the ability to
  93     upgrade a single package independently of the whole system.
  94     Although this should not be abused (we don't want to become
  95     like Linux where on an average system nothing quite matches
  96     anything else), it would provide an ideal way to distribute
  97     important patches and security fixes.
  98
  99     For example, the security patch for NetBSD-SA1998-004 (at(1)
 100     being usable to view any file) was distributed as a patch to
 101     the NetBSD-1.3.2 source tree.  This requires anyone who wishes
 102     to install the fix to have a source tree available, download
 103     and apply the patch, and then rebuild at(1).
 104
 105     In a system based on install systems, an updated version of
 106     the specific package containing at(1) could be released, which
 107     users could download and pkg_add in a matter of moments.  It
 108     would also be easy for an admin to tell if a system had been
 109     upgraded by looking at pkg_info output.
 110
 111 $Id: NOTES,v 1.1.1.1 2002/01/07 22:46:16 jwise Exp $