1I have been spending a lot of time lately thinking about how we 2can extend our current package system to allow the use of system 3packages (and sets thereof) rather than tarballs as our primary 4way of installing NetBSD systems. What follows is a random jumble 5of thoughts on where we can go with this. Based on people's response 6to this, I will put together a more concrete proposal soon. 7 81. 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 432. Package Registration 44 45 Currently, packages are installed in /usr/pkg and /usr/X11R7, 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 623. 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 894. 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.2 2021/11/02 22:02:42 abs Exp $ 112