-----BEGIN PGP SIGNED MESSAGE-----

On Wed, 23 Sep 1998, Todd Vierling wrote:

>:     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.
>
>Known.  Planned.  Not known when we'll do this.  It probably will start with
>the current set layouts as pkgs.  Higher granularity would come later.

I am currently looking into taking a stab at this, as suggested by
Jason.  I'll post a proposal for how I would like to approach this in
the next day or two.  Hopefully, out of n rounds of feedback and
modifications, we can reach something we don't all hate, and I'll start
gluing something together.  If I'm stepping on any toes by proposing
this, hopefully the stepped-upon will holler loudly.

>:     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.
>
>Probably.  Fortunately,pkgs are also tar-files, so it should be possible to
>have sets dump pkg info into /etc/pkg as part of the tarball.

There are a couple of good ways to do sets.  Jonathan Stone forwarded a
summary of some previous off-list discussion of this, including the
proposal that sets be tarballs of binary packages, with a contents file
of their own.  Installing a set would be equivalent to installing the
constituent packages, and the contents file would be saved, to allow
de-installing the entire set.  More advanced users would thus have the
flexibility of installing at the package level, if they prefer.

>:     In order to move to using system packages, we will need to
>:     provide a way to generate binary packages from our source tree.
>
>That's rather simple:  write up a fake set of PLIST, COMMENT, DESCR files to
>send to pkg_create(1).

True.  The real question is how to do this for system packages.  The way
we choose should be central, easily maintainable, and easily automatable
from the system Makefiles.  Something akin to the current (cd
/usr/src/etc && make distrib) should be possible, and the result should
be sets of binary packages, from which system binaries can be installed
at either the set or the individual package level.

>:     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.
>
>Definitely a plus, but we really need to distribute security patches as
>binaries anyway.  Cross-compilation will help this case immensely.

I agree completely.  The proposal is that future security fixes would
ship as binary system packages, as well as source patches.  A busy
sysadmin could then do something akin to pkg_add netbsd15_SA1998-004.tgz
(name hypothetical, of course).

- -- 
				Jim Wise
				jwise@unicast.com



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

iQEVAwUBNgk1+4kLDoBfn5jPAQGWWwf8CGIgrLB3PtmGEzamF+uqUx3DWew/Qc+D
jLkkVQylN1c3/NWGs19agc/oL54YwKc4l8rxbRIpUr3TTOl8FLG7+et7n7nuNeO4
3EPsG36pgDdf19e/B2NGHVtI491mBa6mP8XUJWwEQ77cUK0sE2N+y7GJb6GkuK9K
lj+z3gQ1XtOQ4YYFwaqQQ1VYnb4//MbvynOlObiILoA5xseecLvLB0s0wR4HLRKA
kQqxRnjmxpTIBH8O0tHM5XSOC9UQafDjiY7LQumWuZi8BXThVJXNbKWnuXvasAXl
obZUa1sT+uAt0y1FlIx+VrGz0UBT1VcHfrm3vmwLo8LUGTFrvJD/Nw==
=8syZ
-----END PGP SIGNATURE-----