On Sat, Nov 22, 2014 at 8:51 AM, Andreas Cadhalpun <andreas.cadhal...@googlemail.com> wrote: > Hi, > > On 22.11.2014 10:11, Fabian Greffrath wrote: >> >> I have two more ideas regarding this issue: >> >> 1) We have two library packages that conflict with each other. Why don't >> we have two -dev packages that conflict with each other, then? >> >> I suggest to introduce a new libavcodec-extra-dev package that depends >> on "libavcodec | libavcodec-extra" and change the libavcodec-dev package >> to only depend on the regular libavcodec. The shlibs need to get >> adjusted accordingly, of course. >> >> This way, maintainers have a means to consider the possible license >> clash at build time and we dont have to juggle conflicts with virtual >> packages. > > > 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" > >> 2) There seem to be only very few packages which are at risk of a >> license clash when the libavcodec-extra package is installed. However, >> we currently treat this as the rule, not the exception. > > > 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. But for jessie + 1 if the change is done early, this gives plenty of time for maintainers to adjust. > >> I suggest to turn the situation around and provide the GPLv3 codecs in >> the regular libavcodec package. For the few package for which this could >> impose a license problem, we should provide an extra GPLv2 package. >> >> >> So, together with my first proposal this would result in the following >> package situation: >> >> libavcodec-dev depends libavcodec | libavcodec-gpl2 >> libavcodec-gpl2-dev depends libavcodec-gpl2 >> libavcodec provides all codecs, even the gpl3-compatible ones >> libavcodec-gpl2 provides only the gpl2-compatible codecs >> libavcodec-extra* is no more >> >> What do you think? > > > 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. -- Saludos, Felipe Sateler -- 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/CAAfdZj-gqoBzCzZ2_S9HbxQ+4PScnHTwL12rv8Y2Wh=gvko...@mail.gmail.com
