Re: reasons for split of libavcodec54 and libavcodec-extra-54, missing codecs and a metapackage.

[Reinhard Tartler <siretart@gmail.com>]

On Thu, Nov 20, 2014 at 9:02 PM, Jonas Smedegaard <dr@jones.dk> wrote:
> Hi Reinhard,
>
> Quoting Reinhard Tartler (2014-11-20 21:45:56)
>> On Nov 20, 2014 3:01 PM, "Jonas Smedegaard" <[1]dr@jones.dk> wrote:
>>> Quoting Andreas Cadhalpun (2014-11-20 17:09:49)
>>>> On 19.11.2014 13:09, Jonas Smedegaard wrote:
>>>>> Possibly we can simplify even further:
>>>>>
>>>>>  * Have package libavcodec-extra-NN provide virtual
>>>>>    libavcodec-extra (i.e. non-versioned name of itself)
>>>>>  * Let GPLv2 packages conflict against libavcodec-extra (i.e. not
>>>>>    replace but complement existing suggests/recommends/depends).
>>>>>
>>>>> How does that sound?
>>>>
>>>> This sounds good, except that the virtual package needs another
>>>> name, because libavcodec-extra is actually a real package [1].
>>>
>>> I don't see a problem in conflicting both with virtual provisions of
>>> the package and the real package - as the latter seems to me to
>>> provide nothing beyond pulling in latest of those same virtual
>>> provisions.
>>
>> I'm pretty sure that this approach makes it impossible to have a
>> versioned dependency on libavcodec-extra. Not sure if there is an
>> actual need for this, though.
>
> Now you get me curious: How would providing a virtual package make it
> any more difficult to depend versioned on a package?


AFAIUI, if you have libavcodec-extra both virtual and real, then
application packages can no longer declare:

Depends: libavcodec-extra (>> 6:11)

And reliably expect that the version constraint is obeyed. Or am I
missing something?

> Is it more difficult to depend versioned on e.g. apache2, which provides
> httpd and httpd-cgi?

I believe it is also not possible to reliably declare:

Depend: httpd (>> 2.0)

Reinhard

PS: Wouldn't that be great to have ensure to have a Web 2.0 service
installed? ;-)

-- 
regards,
    Reinhard