Re: packaging system (was: Re: GCC 3.3.2 kernel)

[Chris Pressey <cpressey@xxxxxxxxxxxxxxx>]

On Thu, 30 Oct 2003 18:33:51 +0100
Emiel Kollof <coolvibe@xxxxxxxxxxxxxxxx> wrote:

> [...]
> As far as I care, the current BSD packages are fine as they are as
> packages, but the managing of those packages (/var/db/pkg,
> portupgrade, etc etc) needs to be overhauled.

FWIW I agree.  Advances in this area are probably going to come in small
steps anyway - might as well work with what was inherited, to start.

Rambling along those lines:
I'm tempted to suggest re-thinking the use of 'make' in port-building. 
I suspect the actual strengths of make are being underused.  Isn't it
a bit ironic that most port makefiles look like shell scripts while the
job of *detecting stale dependencies* is done by a Ruby script?  :)

There's also an interesting little issue that occurred to me a while
ago, and I'm not sure there's any packaging system available which
addresses it (although please do enlighten me if anyone happens to know
of one - I'm not terribly well-read on apt, dpkg, etc.)  The issue is
that the dependency tree for a package or port is usually, but not
always, static.  The case for when it is static is well-understood and
usually handled well.  The case for when it can vary, OTOH, is not.

Example: say you have a graphical text editor built upon Motif (e.g.
nedit.)  You can build and run it with either OpenMotif or LessTif.  If
you already have LessTif installed, and the package declares OpenMotif
as a dependency - nothing good can come of it!  Yes, you can put
USE_LESSTIF (or whatever it is) in make.conf to try to address the
problem, but a proliferation of package-specific switches just
complicates the whole process IMHO.  It would be slightly better to have
a single port called, say, 'Motifalike', that builds either OpenMotif or
LessTif depending on your preference, and have every Motif-dependant
port specify Motifalike in its dependencies.  Even slightly better than
that might be to specify Motif not as a package, but as an 'interface'
to which any number of packages might conform.

Probably more of an annoyance than an actual problem for most people,
but I thought it might be an interesting 'hmm'-point for anyone who's
thinking about the packaging system.

-Chris