[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 22.11.2014 13:48, Felipe Sateler wrote:

On Sat, Nov 22, 2014 at 8: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.


I believe what is missing is that libav*-dev should all depend on
libavcodec-dev | libavcodec-gpl2-dev.
Then it can just fine build-depend on "libavformat-dev, libavcodec-gpl2-dev"
I don't think that would change anything. The problem with libkfilemetadata4 is that the dependency on libavcodec comes indirectly, from libavformat, and not from linking against libavcodec. 
Therefore a build-dependency change can't solve this.
It requires either a manual dependency on libavcodec-gpl2 or a manual conflict with libavcodec-gpl3.
Adding such manual dependencies on generic packages provided by the versioned library packages seems like the best possible solution. 


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.


Of course, this cannot be done for jessie.


Sure, jessie is already frozen.


But for jessie + 1 if the
change is done early, this gives plenty of time for maintainers to
adjust.


Maybe.


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 would propose the following transition plan:

Step 1: libavcodec-dev depends on libavcodec-gpl2-dev
Step 2: Ping all rdeps maintainers with this change.
Step 3: swap the dependencies of libavcodec-dev


I would also add that libavcodec-gpl2-XY should Provide:
libavcodec-gpl2 (ie, an unversioned name) so that packages that
conflict with gpl3 can do so easily by depending on the virtual
package. Or alternatively do similarly with libavcodecXY providing
libavcodec-gpl3 and making packages Conflict with that virtual
package.
This might work, but it still seems like a lot of work, just to have one more encoder. 

Best regards,
Andreas
Reply to: