Re: reasons for split of libavcodec54 and libavcodec-extra-54, missing codecs and a metapackage.
Hi,
On 18.11.2014 01:25, Reinhard Tartler wrote:
On Mon, Nov 17, 2014 at 5:53 PM, Andreas Cadhalpun
<andreas.cadhalpun@googlemail.com> wrote:
All of them have an alternative dependency on libavcodec-extra-56, which is
strictly speaking a license violation.
Probably appropriate Conflicts relationships between them and
libavcodec-extra-56 are necessary.
Well, I've heard some claims about that, but I am not absolutely sure.
To be sure one would have to ask a lawyer...
Libavcodec-extra-NN was definitly not present at compilation/link time
of any of the packages above. We also don't require users to use the
affected binary packages against libavcodec-extra-NN packages.
Technically, I also don't see Debian violating any license by allowing
this alternative dependencies.
I see, so Debian itself is not directly violating the licenses.
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.
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?
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.
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.
However, I wonder if the few additional codecs in the extra package are
worth all the additional complexity. How many actually use these codecs?
We used to ship x264 in the -extra- package, which is very popular.
Yes, x264 is certainly rather popular, but fortunately it's now enabled
in the main libavcodec package
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?
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.
Thus maybe it'd be better to not mark the native aac encoder as
experimental anymore. That could be discussed upstream.
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.
I would say that effort is very much worth it!
Given the cost (having to deal with the license problems)/benefit (being
able to encode AMR) ratio, I'm not convinced about that.
Best regards,
Andreas
1:
https://www.debian.org/doc/debian-policy/ch-sharedlibs.html#s-shlibs-paths
2: https://tracker.debian.org/media/packages/p/poppler/copyright-0.28.1-1
3: https://ffmpeg.org/pipermail/ffmpeg-devel/2013-June/144589.html
Reply to: