Re: reasons for split of libavcodec54 and libavcodec-extra-54, missing codecs and a metapackage.
On Tue, Nov 18, 2014 at 5:55 PM, Andreas Cadhalpun
<andreas.cadhalpun@googlemail.com> wrote:
>> What could be considered problematic is that users technically do a
>> license violation by installing libavcodec-extra-NN together with
>> GPLv2 only packages. On might construct a situation where some Debian
>> user creates an appliance that uses one of the packages above and
>> install libavcodec-extra-NN. I could imagine that this situation might
>> be problematic for that user.
>
> Indeed, that's a problem. Debian should protect its users from such license
> problems.
I tend to agree.
>> What can we do about this in Debian? Well, I don't really feel like
>> maintaining a list of packages that are GPLv2 only in debian/control.
>
> Yes, it'd be difficult/time-consuming to create/maintain such a list of
> packages, e.g. due to library transitions.
>
>> Instead, I'd very much prefer those packages to install a shlibs.local
>> file that avoids the alternative dependency on the -extra- flavor.
>
>
> Debian Policy says about debian/shlibs.local:
> "This file should normally not be used" [1]
>
> One could argue that the situation of the libavcodec-extra-NN packages falls
> under the "unusual cases where the normally declared dependency information
> in the installed shlibs file for a library cannot be used".
> But still, it doesn't look like an optimal solution.
>
> Furthermore I don't think it can always work.
> For example look at the dependencies of libkfilemetadata4:
> * libavformat56, which depends on libavcodec56 | libavcodec-extra-56
> * libpoppler-qt4-4, which depends on the GPL v2 only [2] libpoppler46
> How could a shlibs.local file help here?
The shlibs.local file would contain something like this:
libavcodec 56 libavcodec56 (>= 6:11~beta1)
> And how would library transitions be handled?
> The libavcodec soname would have to be figured out in debian/rules at
> build-time, making this even more complex.
Indeed. Since this only applies to a handful of packages, I think this
can be handled manually for now. But I give you that point:
Maintaining the shlibs.local file is laborious and thus error-prone.
Maybe we can play tricks with dependencies instead: Let's have a
"libavcodec-noextra" package (stable package name) that conflicts
against the "libavcodec-extra-NN" (NN change on SONAME bumps). GPLv2
binary packages can then depend on libavcodec-noextra to implement
your concern.
Does that make more sense?
> However, the biggest problem is:
> Who is supposed to check which libavcodec using packages are GPL v2 only
> (maybe just because of linking against a GPL v2 only library)?
> The maintainers of these packages can't be expected to know about the
> problem with libavcodec-extra-NN. At least they haven't done anything about
> it yet, so it's unlikely they will start doing so on their own.
This is were I disagree. I believe that it is the task of the package
maintainers to check both the license of the sources, as well as the
effective license of the generated binary files.
>> I suppose that many users are very interested in the AAC encoders,
>> because the native encore inside libavcodec is of rather poor quality.
> Do you know of specific problems the native encoder has, which are not
> present in the libvo_aacenc encoder?
Sorry, I'm not up to speed with the details, but you have to be aware
that AAC (like many other modern codecs) comes with lots of optional
features, check for instance
http://en.wikipedia.org/wiki/Advanced_Audio_Coding to get a flavor. I
have to admit that I lost track which AAC encoder supports what
features, how many tracks, etc, but I do know that vo-aacenc
originates from the Android code base and at least at the time it was
released, many people found it useful compared to the native aac
encoder.
> From what Jonas wrote and what is mentioned on the FFmpeg Wiki, e.g. the
> mailing list post [3], it seems the libvo_aacenc encoder is worse than the
> native one.
I don't know for sure, I guess this would be a great question for
Kostya or Alex.
> Thus maybe it'd be better to not mark the native aac encoder as experimental
> anymore. That could be discussed upstream.
Agreed.
>
>> Also, AMR seems also be rather popular if you own a device that
>> requires that codec.
>
> There is already a native AMR decoder, so the only thing that can't be done
> without the libavcodec-extra-NN package, is encode AMR.
Correct.
--
regards,
Reinhard
Reply to: