On Thu, Feb 22, 2001 at 09:46:53AM +0000, Mark White wrote:
> Todd Vierling writes:
> > ...has got to go.  Currently, perl-dependent packages are depending on perl,
> > perl-base, p5-CGI, p5-Data-Dumper, etc.  So how will they cope when perl
> > gets updated and these packages are part of perl-base again?

I agree with Todd on this one.
 
> 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.

That we use different tools to the ones used by other utilities in
the system (rcorder springs to mind, but PLEASE let's not go there),
is neither here nor there, since we have different requirements (the
conflicts information, for example).
 
> As somebody remarked, registering one level deep only would
> be perfectly acceptable, and in some ways much more
> sensible, that recursive registration into a single package.
> The PROVIDES field might be quite useful anyway, though...

Well, it depends what you're going to put in the fields for provides,
and requires, but what would we gain by doing it differently to the
way we currently do it?

Regards,
Alistair