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

[Felipe Sateler <fsateler@gmail.com>]

On Sat, Nov 22, 2014 at 8:51 AM, Andreas Cadhalpun
<andreas.cadhalpun@googlemail.com> wrote:
> Hi,
>
> On 22.11.2014 10:11, Fabian Greffrath wrote:
>>
>> I have two more ideas regarding this issue:
>>
>> 1) We have two library packages that conflict with each other. Why don't
>> we have two -dev packages that conflict with each other, then?
>>
>> I suggest to introduce a new libavcodec-extra-dev package that depends
>> on "libavcodec | libavcodec-extra" and change the libavcodec-dev package
>> to only depend on the regular libavcodec. The shlibs need to get
>> adjusted accordingly, of course.
>>
>> This way, maintainers have a means to consider the possible license
>> clash at build time and we dont have to juggle conflicts with virtual
>> packages.
>
>
> That's a nice idea, but just as the shlibs.local method, it doesn't work in
> all cases. See my previous example of libkfilemetadata4, which would still
> have the problem, because it only indirectly depends on libavcodec (via
> libavformat) and thus can't change the libavcodec dependency.

I believe what is missing is that libav*-dev should all depend on
libavcodec-dev | libavcodec-gpl2-dev.
Then it can just fine build-depend on "libavformat-dev, libavcodec-gpl2-dev"

>
>> 2) There seem to be only very few packages which are at risk of a
>> license clash when the libavcodec-extra package is installed. However,
>> we currently treat this as the rule, not the exception.
>
>
> The problem here is that it might seem to affect only few packages, but
> nobody has really looked, so we can't know. In particular, it's hard to
> verify that none of the libraries (indirectly) linked are GPL v2 only.

Of course, this cannot be done for jessie. But for jessie + 1 if the
change is done early, this gives plenty of time for maintainers to
adjust.

>
>> I suggest to turn the situation around and provide the GPLv3 codecs in
>> the regular libavcodec package. For the few package for which this could
>> impose a license problem, we should provide an extra GPLv2 package.
>>
>>
>> So, together with my first proposal this would result in the following
>> package situation:
>>
>> libavcodec-dev depends libavcodec | libavcodec-gpl2
>> libavcodec-gpl2-dev depends libavcodec-gpl2
>> libavcodec provides all codecs, even the gpl3-compatible ones
>> libavcodec-gpl2 provides only the gpl2-compatible codecs
>> libavcodec-extra* is no more
>>
>> What do you think?
>
>
> Before enabling the GPL v3 codecs by default someone would have to check all
> reverse dependencies, whether they would be compatible. That means not only
> to check for GPL-2 only in all reverse-dependencies, but also in their
> linked in libraries and if any of the more exotic licenses of some (parts)
> of them would indirectly imply GPL-2 only.

I would propose the following transition plan:

Step 1: libavcodec-dev depends on libavcodec-gpl2-dev
Step 2: Ping all rdeps maintainers with this change.
Step 3: swap the dependencies of libavcodec-dev


I would also add that libavcodec-gpl2-XY should Provide:
libavcodec-gpl2 (ie, an unversioned name) so that packages that
conflict with gpl3 can do so easily by depending on the virtual
package. Or alternatively do similarly with libavcodecXY providing
libavcodec-gpl3 and making packages Conflict with that virtual
package.

-- 

Saludos,
Felipe Sateler