Bug#658084: libav-extra: Really necessary?

[Reinhard Tartler]

On Wed, Feb 1, 2012 at 11:49 AM, Jonas Smedegaard <dr at jones.dk> wrote:
> On 12-02-01 at 10:24am, Fabian Greffrath wrote:
>> Am 31.01.2012 17:55, schrieb Reinhard Tartler:
>> >Legally, I don't think there is much difference here. However, there
>> >is a practical difference for Debian as distribution: we do not
>> >violate the packages if users install a combination of packages that
>> >result to a license clash. Yes, we can add conflicts, and probably
>> >have to if we become aware of it, but we cannot be held responsible
>> >for funky stuff that random users do on their (own) systems.
>>
>> Reminds me of the libcurl situation. We have both libcurl (linked
>> against openssl) and libcurl-gnutls packages in Debian. The latter is
>> for packages with licenses incompatible to openssl's one. However,
>> nothing prevents you from installing the openssl-linked libcurl
>> package on your system if you wish so.

I didn't check the curl situation, but yes, that sounds a bit similar.

> I believe multiple flavors of libcurl is installable concurrently, which
> means dependent packages can link against a specific one as licensing
> requires.
>
> With libav you provide no way for dependent packages to ensure their
> licensing is respected.
>
>
>> What parts of libav are actually affected by the two additional
>> codecs? I guess it's only libavcodec (and maybe libavformat).

Well, in detail, it affects two additional build dependencies, which
are then detected at build time if present by debian/confflags. These
enable the respective library wrappers.

> If it
>> really boils down to rebuild only one library with aditional
>> confflags, I begin to like Andres' idea more and integrate libav-extra
>> into the libav package.
>
> If ok legally then certainly that's most elegant.

Sorry, I disagree with that approach. It a) increases the complexity
of the packaging considerably, b) doubles the build-times and c)
doesn't help at all with keeping the diff for ubuntu minimal.

-- 
regards,
    Reinhard