Subject: Re: micro-pkgizing the system
To: None <>
From: Alistair G. Crooks <>
List: tech-pkg
Date: 02/02/2000 07:07:32
> This reminds me, I hacked together some bits to pkgize the base system
> last weekend:
>   # cd /usr/src/bin/ls
>   # make install
>   # pkg_info -e netbsd-'*'
>   netbsd-bin-ls-1.4Q
>   # rfhpc8321# pkg_info -qL netbsd-bin-ls-1.4Q
>   //bin/ls
>   //usr/share/man/man1/ls.1
>   //usr/share/man/cat1/ls.0
> Works for most dirs in /usr/src so far, MLINK handling is not ok yet. If
> someone wants to play with it, .include the script at
> from your /etc/mk.conf. This
> also works for DESTDIR bilds, which creates binary packages instead of
> registering them locally:

I worked for a company which distributed its operating system as
a large number of very small packages - i.e. one for ls(1), one
for du(1). This had certain advantages, and certain disadvantages.
The disadvantages included the sheer amount of work involved, the
overhead in keeping tabs on installed packages, conflicts between
such small packages, rolling out changes which impact a whole
subsystem, and changes in libraries requiring all statically-linked
binaries having to be repackaged and distributed anyway. OK, so I
lied, there weren't any advantages.

The script I checked in was intended to make the file lists (which
include dirs, symlinks, etc) in distrib/ be able to be converted
into a PLIST. That seems to be the first point of attack for anyone
looking at using the pkg_* tools to install and manage the base
system, but differing least from what we have at the moment, which
developers find to be useful. We also need a tool to take the
obsolete lists, and convert them into a +CONTENTS-style list,
complete with MD5 sums (or ignore checksum entries), so that previous
components can be deleted when upgrading, or when binaries have
moved directories.

Not belittling your work, just a datapoint.