Subject: Re: Recursive package dependency registration...
To: Alistair Crooks <firstname.lastname@example.org>
From: Mark White <email@example.com>
Date: 02/22/2001 12:50:26
Alistair Crooks writes:
> On Thu, Feb 22, 2001 at 09:46:53AM +0000, Mark White wrote:
> > Wouldn't it be nice to implement a 'PROVIDES' field in the
> > package system? Then, then pkg widget-2.1 takes over the
> > functionality of widget-2.0 and thingy-1.4, you just add
> > "thingy-1.4" to the PROVIDES list. Having it there will
> > satisfy the dependencies of any older package that relies on
> > thingy-1.4.
> If you're proposing that we provide a general provide and require
> mechanism, I think we'd all agree with you.
> The question that I have is: what is going to be put in the require
> and provide fields? Simply package names, as you imply above?
> If it is the package names that you put in there, then it also strikes
> me as being redundant, however. We have the provides part there in
> the package name, and the requires part in the dependencies and
> conflicts fields.
Well, I wasn't suggesting it as a replacement for handling
dependencies using DEPENDS and other package names; it's an
idea for making sure old packages don't break when something
they depend on gets assimilated into something else.
Perhaps 'SUPERCEDES' would be a better name; you just add to
it the names of other [earlier] packages X and Y who's
functionality has been absorbed by package Z.
Then, when some other package [also older, and probably
already installed] has X in it's DEPENDS field, the
dependency needs to be satisfied *either* by X being
installed, *or* by some package with X in the SUPERCEDES
field being installed. => Z can be upgraded and X removed
without breaking packages depending on X.
Does that help? Quite possibly I missed the point... :-)