Hi,
On 19.11.2014 04:02, Reinhard Tartler wrote:
On Tue, Nov 18, 2014 at 5:55 PM, Andreas Cadhalpun
<andreas.cadhal...@googlemail.com> wrote:
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)
From my understanding of the shlibs mechanism, that wouldn't have any
effect in this particular case, because libkfilemetadata4 does not
*directly* depend on libavcodec, only on libavformat.
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?
That's better. Jonas' suggestion of using a virtual libavcodec-extra
package looks even simpler.
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.
You're right, they should check the licenses. What I wanted to say is
that I don't expect them to suddenly realize this license issue in the
near future, because they haven't done so until now.
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.
Then let's move this discussion upstream.
Best regards,
Andreas
--
To UNSUBSCRIBE, email to debian-multimedia-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/546e09b9.3090...@googlemail.com
