On Jul 30, 2005, at 15:24:05, Alexander Hansen wrote:
IMO we shouldn't have 'bar' provide 'foo' as well as have a
separate 'foo' package. This is a continual source of chaos.
We should have a common functionality e.g. 'foo-bar', and
then both 'foo' and 'bar' can provide 'foo-bar'.
In this case we could either have "fink remove foo-bar"
remove the package that provides 'foo-bar' or throw an error
stating that it's a virtual package. No ambiguity.
Uhh, what about this reasonably probable example:
Say we're packaging the "host" command, for which multiple
implementations exist. Yes, Apple provides this one, I know,
but bear with me here, it's a decent real-world example.
Say we have a "host" package that provides a standalone host
implementation. Let's also say that we have a "bind9"
package, which happens to include a different "host" command
that can use the BIND lightweight resolver library. It
should be possible to have these:
Package: host
Conflicts: bind9
Replaces: bind9
Package: bind9
Provides: host
Conflicts: host
Replaces: host
Now, I _do_ agree that it probably is a terrible idea to have
packages x and y where y provides x but does not conflict
with it. In such a case, two programs providing the same
functionality would be _guaranteed_ (absent dpkg-divert) to
have filename conflicts, assuming they actually provide the
same functionality.
Cheers,
Kyle Moffett
--
Premature optimization is the root of all evil in programming
-- C.A.R. Hoare
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel
