Re: Packaging of base system

On Tue, May 10, 2005 at 07:34:16AM -0700, Bruce A. Mah wrote:
> Honestly I'm not sure if I like this idea or not.  My most recent
> experience with a fully packaged system is with RH/FC Linux
> distributions and many times I feel like I'm in a twisty little maze of
> RPMs, all different.

... and with dependency nightmares, indeed.

> You seem to be proposing a more coarse-grained
> packaging, which I think is more workable.

Yep. I think we can start with the current 'distribution sets' as a
baseline, although personally I would like to see split out:

- all compilers, debuggers, development tools into one dist set
- text processing tools into another

as both are not needed for a "run time" server environment. You need to be
careful how far you go down that road; e.g. things like cvs, rcs, diff,
patch can be used for system administration as well as development, so I
think they should remain in the base. "strip" and "ldd" are borderline cases
which probably should remain in the base too.

Then arguably, separate packages for:

- sendmail (no need to install it if you are using a different MTA)
- bind (because it's big and not needed on most nodes)
- /boot (to allow easier building of arrays of machines with custom
  kernels, and because pxeboot systems may not need it on their root FS)

Any finer granularity introduces dependency problems: for example, although
it might sound convenient to have ssh packaged separately to make it easier
to upgrade, it probably isn't by the time you've considered
interdependencies on libcrypto/libssl and everything else that in turn
depends on those libraries. So I'd leave fixing that to the 'binary update'
project, and to -RELEASE upgrades.

To get an idea of the sizes involved, I wrote a program using libarchive
which splits the existing FreeBSD base.?? distribution into smaller tarfiles
using a control file indicating which output bin each source file goes into:
the results are

-rw-r--r--  1 brian  brian  12259050 May  9 11:49 splitbsd-5.4-base.tar.gz
-rw-r--r--  1 brian  brian   3739936 May  9 11:49 splitbsd-5.4-bind.tar.gz
-rw-r--r--  1 brian  brian   7895611 May  9 11:49 splitbsd-5.4-boot.tar.gz
-rw-r--r--  1 brian  brian  17848825 May  9 11:49 splitbsd-5.4-devel.tar.gz
-rw-r--r--  1 brian  brian   2085982 May  9 11:49 splitbsd-5.4-doc.tar.gz
-rw-r--r--  1 brian  brian    287388 May  9 11:49 splitbsd-5.4-legacy.tar.gz
-rw-r--r--  1 brian  brian    810702 May  9 11:49 splitbsd-5.4-netif.tar.gz
-rw-r--r--  1 brian  brian    371588 May  9 11:49 splitbsd-5.4-nisker.tar.gz
-rw-r--r--  1 brian  brian    663606 May  9 11:49 splitbsd-5.4-sendmail.tar.gz
-rw-r--r--  1 brian  brian   1164703 May  9 11:49 splitbsd-5.4-text.tar.gz

# base          = core components for a functioning system inc. shell scripting
# boot          = kernel, modules, everything under /boot
# devel         = development libraries, compilers, source code debuggers,
#                 and anything which generates C code as its output
# text          = document processing tools, man page tools
# doc           = documentation and examples
# netif         = unusual network interfaces (atm, netware, bluetooth, isdn,
#                 slip)
# legacy        = Insecure services, e.g. finger(d), rexec(d), rlogin(d),
#                 telnetd; desk toys (e.g. cal); BSD legacy (e.g. enigma)
# sendmail      = sendmail
# bind          = bind
# nisker        = NIS and kerberos

It's interesting that compilers, examples/openssl manpages and bind between
them account for half the base system (23200K out of 46272K compressed).
Just being able to leave these out would be useful for the sorts of system
that nanobsd targets.

Regards,

Brian.