Bug#681136: Should libavcodec-extra-53 Provides: libavcodec53? [Was: Re: Bug#681136: libavcodec-extra-53: Cannot install libavcodec-extra-53 without losing kde]

[Reinhard Tartler]

On Wed, Jul 11, 2012 at 10:07 PM, Fabian Greffrath <fabian at greffrath.com> wrote:
>> The problem appears to have been that I had not succeeded in removing all
>> Marillat's packages, despite trying to make sure I had before reporting
>
> I suspected this. :)
>
>> After reinstalling all the vlc (and xine) related packages I was able to
>> install libavcodec-extra-53.
>
> At least.
>
>> I still think it would have been easier if libavcodec-extra-53 had either
>> Provides: libavcodec53 or, even better, really was just extras without
> I don't see any reason against this approach but leave it up for
> discussion with the other team members (then this big should get closed).


That would make 'libavcodec53' a "virtual" package, which AFAIUI would
break versioned dependencies as dpkg does not support "versioned
provides".

>
>> replacing libavcodec53 at all.  However, I am sure you have good reasons
>> for this packaging.
>
> Unfortunately, it is not possible to package the "extra" parts alone, so
> both libraries need to replace each other.

It would require invasive modifications to libavcodec to load all
libraries that are only included in the -extra- variations at run-time
via dlopen(). It seems to me that this approach has a number of corner
cases to figure out (most importantly: at what time can libavcodec
decide if a codec is available or not - moreover dlopen() is not
available on all platforms that libav supports), and is therefore not
really a favored approach by upstream.

-- 
regards,
    Reinhard