Subject: Re: Virtual packages and package classes
To: None <tech-pkg@NetBSD.org>
From: None <email@example.com>
Date: 06/27/2006 16:48:48
On Tue, Jun 27, 2006 at 03:54:31PM +0200, Dieter Baron wrote:
> : The first problem is about packages which need a certain feature from
> : other packages, but don't care about the concrete implementation. For
> : example, mail/mailman is a lot less useful, when no web server with CGI
> : support is installed.
> It does not *need* a web server though, so requiring one via
> dependencies is wrong. Also, it will need to be set up (manually?) to
> work with the web server, right? If glue files are needed, maybe they
> can be provided by a separate package.
Well, mailman "needs" a web server as much as it "needs" a MTA. The
user interface is written with the assumption that most users will have
and utilise the web interface. I believe that using mailman without a
web browser is an unusual configuration.
> : Another example is given by the family of browser plugins. They don't
> : really care whether it is Firefox, Opera or even Netscape 4.7, as long
> : as the interface version is provided.
> They need to install (or symlink) into different directories for
> each browser. Do you suggest to solve this via triggers?
Either pkgsrc would configure them to check in a shared directory by
default (we might actually have that already), or yes, via a trigger.
> Or do you mean at build time, for providing the header files?
This is also a problem, since e.g. both Firefox or Mozilla/Seamonkey can
be used to build plugins with.
> The depency chosen at build time may affect which packages are
> acceptable as dependency at run time (e. g. if the dependencies are
> API compatible, but not ABI compatible).
I *think* we have a clear ABI interface, but it would have to checked on
a per-plugin base. That's part of the problem, e.g. Netscape 4.7 plugins
should be compilable and linkable even with the newer versions.
> : A package can tag the PLIST to invoce the trigger for a specific file,
> : e.g. like:
> : @trigger TTF
> : lib/X11/fonts/X11/geni102.ttf
> : @trigger TTF
> : lib/X11/fonts/X11/genr102.ttf
> I like the idea of triggers, but I don't like the proposed syntax.
> I think the PLIST is the wrong place for this information. Also, I
> would very much like to get rid of multi-line entries (or entries that
> refer to the next/previous entry) in the PLIST.
First about the question of using the PLIST or not. I believe that it is
meta-data attached to a file ("This is a TrueType font.") or a directory
("This directory contains TrueType fonts."). Based on this I think the
PLIST is the correct place.
For the actual syntax and the multi-line entries, I still haven't found
a perfect solution. The situation is even made more difficult by the
desire to use it as output from the pkg tools later. As opposed to the
PLISTs in pkgsrc/*, we have additional information (like the hashes).
I also want to allow the annotation of special permissions (e.g. owner,
mode) directly in the PLIST of the build system, but that's a long term
goal. We discussed parts of this on pkgrsccon.
I don't care about postfix or prefix syntax, both have merits. For
humans postfix is most likely a bit easier to read as it follows the
usual conventions of head line and content.
> : This does not solve the problem how to determine whhich package to
> : install to fullfil the trigger requirement.
> I don't think triggers should add dependencies: It makes perfect
> sense to install a TTF font without any package that uses it (e. g. if
> I use it outside pkgsrc). Also, it make perfect sense to install
> ghostscript without additional TTF fonts.
Both examples are fine and must work. I have to lay out rules for the
execution order, but that's not the problematic situation.
Ignoring for a moment the inability to express dependencies for the test
target, Firefox and all other Mozilla applications *need* a locally
installed font (I think the format doesn't matter). Otherwise they can't
run (segfault on startup). So this is not a soft-dependency, but a hard
requirment for the program to run. The earlier examples could fall into
this category as well.