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

[Alexander H. <ak...@co...>]

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/