Virtual packages (was Re: Bug#64006:)
Julian Gilbey <J.D.Gilbey@qmw.ac.uk> writes:
> On Sat, May 13, 2000 at 01:05:42PM -0700, Chris Waters wrote:
> > Two things I'd like to see done with the virtual package system:
> > 1. Define APIs for all virtual packages.
> > 2. Tie virtual packages to the alternatives system, somehow.
> > The former emphasises the fact that, unless you have *some* sort of
> > common API (no matter how fuzzy), you don't really have a virtual
> > package. The latter may be pie-in-the-sky, but could be interesting.
> But a package which Recommends: www-browser needs no standard
> interface whatsoever, for example.
I believe they all fit this template:
command-line: <package-specific-program-name> <url>
Now, it's cases like this which caused me to mention "fuzziness". I
agree, that's not *much* of an API. But it still sort of is one. If
all virtual packages were that fuzzy, then it would gain us little to
document the API. But there are cases where it goes far beyond that
("mail-transport-agent" for example).
Maybe API is the wrong term, but I think it would be nice to document
whatever it is that we expect from a package that claims to provide
some given virtual package. However minimal our expectations, they
must be non-nil or there really is no point in calling something a
virtual package.
This might be a great help for people trying to create packages that
should depend on (or suggest) virtual packages.
> I think that virtual packages go beyond alternatives.
Oh yes, no question. Sometimes they're mutually exclusive too,
i.e. cases where we might use alternatives except for the fact that
the packages try to use a common resource ("mail-transport-agent"
again, and the smtp port). But that misses my point.
Basically, one of the biggest flaws I see in the alternatives system
is that there is little or no documentation on what sorts of
alternatives the system actually provides. Whereas, we do document
what virtual packages we provide, but not what they do. These
problems seem somewhat related, or at least complementary, and I
thought it might be interesting and useful to consider solving them
together. Maybe. Perhaps.
It seems to me that there are real similarities in what virtual
packages are and do, and what alternatives are and do. And when this
old programmer's brain notices such similarities, it sends out pleas
to codify and exploit them.
As I said, the second idea is still quite pie-in-the-sky. And maybe
it'll never get anywhere, but I still wanted to toss it out. Maybe I
should try the d-dpkg list or something...
cheers
--
Chris Waters xtifr@dsp.net | I have a truly elegant proof of the
or xtifr@debian.org | above, but it is too long to fit into
http://www.dsp.net/xtifr | this .signature file.
Reply to: