Re: [Fink-devel] Treatment of virtual packages, Version 2

[Alexander Hansen]

On Jul 30, 2005, at 5:35 PM, Kyle Moffett wrote: 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 And I'd say here Provides:  host-command Package: bind9 Provides: host (once again Provides: host-command) 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 My addition is a bit facetious, too, in this case.   I don't know if it's actually better or not--I'm more opposed to packages Providing themselves on aesthetic grounds. -- Alexander Hansen Fink Documentarian [Day Job] Levitated Dipole Experiment http://psfcwww2.psfc.mit.edu/ldx/