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

[Reinhard Tartler <siretart@gmail.com>]

On Sat, Nov 22, 2014 at 6: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.

Are you sure about that? Given that libavformat links against
libavcodec, I've never seen a package that depends only on libavformat
but not on libavcodec.

I bleive we are safe, but please correct me.

>> 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.

It's also hard to verify that a package is free of bugs. We deal with
bugs as soon as we become aware of them, and act on them generally on
a case-by-case basis. I consider these license issues as serious bugs
that definitely should be fixed in a timely manner by their package
maintainers, but with very manageable legal risk to Debian.

>> 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 don't think that we really need to do an archive wide license audit
(Andreas, you are still welcome to do so!), but I share Andreas'
concern that this step causes too much churn and work for too little
benefit.

YMMV, of course.

Best,
Reinhard


-- 
regards,
    Reinhard