packaging system (was: Re: GCC 3.3.2 kernel)

[Lewis, Todd]

Dpkg does this with virtual packages.  To use a completely un-fact-checked
example, you depend on "vi", a package that doesn't exist.  Vim, elvis,
etc., all have "Provides: vi" in their specification.  When automatically
filling the dependency, one of these alternatives is picked per the default
policy, or per the user's choice if desired.

This last piece is an apt feature, but those who argue that apt is some pure
essence of platform-independent goodness while dpkg is an abomination of
debian-spcificitude are, to put it politely, stretching their case.
Apt/dpkg/debhelper/dselect are designed and maintained coherently.

-----Original Message-----
From: Chris Pressey [mailto:cpressey at xxxxxxxxxxxxxxx] 
Sent: Thursday, October 30, 2003 4:01 PM
Subject: Re: packaging system (was: Re: GCC 3.3.2 kernel)


On Thu, 30 Oct 2003 18:33:51 +0100
Emiel Kollof <coolvibe at 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