[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 23.11.2014 03:09, Reinhard Tartler wrote:

On Sat, Nov 22, 2014 at 6:51 AM, Andreas Cadhalpun
<andreas.cadhalpun@googlemail.com> wrote:

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.


Are you sure about that?


Yes.


Given that libavformat links against libavcodec,


This causes the indirect dependency.


I've never seen a package that depends only on libavformat
but not on libavcodec.


There's always a first time for everything.


I bleive we are safe, but please correct me.


$ apt show libkfilemetadata4 2>1 | grep Depends
Depends: libavformat56 (>= 6:11~beta1), libavutil54 (>= 6:11~beta1), libc6 (>= 2.14), libepub0 (>= 0.1.1), libexiv2-13, libgcc1 (>= 1:4.1.1), libkdecore5 (>= 4:4.13.0), libpoppler-qt4-4 (>= 0.20.1), libqmobipocket1 (>= 4:4.11.80), libqt4-xml (>= 4:4.5.3), libqtcore4 (>= 4:4.8.0), libqtgui4 (>= 4:4.5.3), libstdc++6 (>= 4.6), libtag1c2a (>= 1.5)
As you can see, it depends directly on libavformat and libavutil, but not on libavcodec. 


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.


It's also hard to verify that a package is free of bugs. We deal with
bugs as soon as we become aware of them, and act on them generally on
a case-by-case basis. I consider these license issues as serious bugs
that definitely should be fixed in a timely manner by their package
maintainers, but with very manageable legal risk to Debian.


Do you mean serious bugs as in release-critical for jessie?
I'm not sure that would be appropriate.


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.


I don't think that we really need to do an archive wide license audit
(Andreas, you are still welcome to do so!),
As I don't know of any simple/automatic method of doing this, I'm afraid I won't do this license audit. 


but I share Andreas'
concern that this step causes too much churn and work for too little
benefit.

YMMV, of course.


Best regards,
Andreas
Reply to: