Re: Packaging of base system

Overall, I think that packaging the base system is a good idea for
end-users.  In theory, it means that upgrades can be handled by a
wrapper around portupgrade and the pkg_* tools can be used to verify
system consistency.  OTOH, I'm not sure that it is of much benefit to
developers - unless you replace "make world" with portupgrade, the
base system package information will be out-of-date following the
first installworld.  It might be useful asking for opinions in some
of the "end user" lists as well as here.

On Tue, 2005-May-10 07:34:16 -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.  You seem to be proposing a more coarse-grained
>packaging, which I think is more workable.

OTOH, Solaris and Tru64 are fully packaged and this seems to work -
though both are (probably too) fine grained.  I suspect that fine
grained makes the dependencies easier to manage, but in the case of
both Solaris and Tru64, working out whether you want a particular
package or not is virtually impossible.  If you do go the fine-grained
approach, it may be worthwhile having a group of "dependency" packages
that are gathered in a section headed "you probably don't want to
individually select these packages - they will be installed
automatically if required".

I suspect the only serious problems will be:
- adapting the source build/install environment to update the relevant
  package info (if you even attempt this);
- handling installing "base" packages that are required by a port[*]
- avoiding circular dependencies;
- handling the bikeshed on which utility goes in which package.

As my input on the last item, I'd suggest that "client" and "server"
tools should be in separate packages: I think that lots more people
will be interested in ftp and telnet than want ftpd or telnetd.  And
whilst few people want named, almost everyone wants the client resolver
libraries (which together form "bind").

[*] This is especially messy if you use fine-grained packaging (so that
    some of the less common libraries might be missing) and the source
    upgrade path isn't integrated into the packaging.

-- 
Peter Jeremy