[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

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. 


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. 


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. 

Best regards,
Andreas
Reply to: