Bug#658084: libav-extra: Really necessary?
Am 21.03.2012 01:40, schrieb Andres Mejia: I would like to upload a package to experimental soon. Anyone have any other suggestions at this time? BTW, I have added a mention of the license impact to libavcodec-extra's decription. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#658084: libav-extra: Really necessary?
On Wed, Mar 21, 2012 at 2:12 AM, Reinhard Tartler siret...@gmail.com wrote: On Wed, Mar 21, 2012 at 1:40 AM, Andres Mejia amejia...@gmail.com wrote: Here are some of the comments Reinhard said on IRC. Placing them here for recording purposes. [02:47] siretart amejia: in the merged case, I think the -dev packages can have tight dependencies on the library packages [02:48] siretart amejia: also, I think only libavcodec changes, so in that case we'd no longer need to provide e.g. libavutil-extra-51 [03:00] siretart amejia: ultimatively, I think this change goes into the right direction. unfortunately, it wont save a lot of effort, because for ubuntu we'll still need libav-extra and this change needs to be reverted there. at least for now :-( With only libavcodec having an extra package, the other extra packages would need transitional packages. Also, I'm afraid the epoch would need to be bumped again. $ dpkg --compare-versions 4:0.8.1-1 le 4:0.8.1.1 echo true true I would like to upload a package to experimental soon. Anyone have any other suggestions at this time? Do you volunteer to do at least the first uploads for libav and libav-extra for ubuntu as well? -- regards, Reinhard Yes, I'll volunteer, but the first thing I would do for ubuntu is a) request libav to be demoted back to universe or b) request all of libav's build dependencies to be promoted to main. You think any of these requests would succeed? -- ~ Andres ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#658084: libav-extra: Really necessary?
On 03/21/2012 06:40 AM, Andres Mejia wrote: On Wed, Mar 21, 2012 at 2:12 AM, Reinhard Tartler siret...@gmail.com wrote: Do you volunteer to do at least the first uploads for libav and libav-extra for ubuntu as well? Yes, I'll volunteer, but the first thing I would do for ubuntu is a) request libav to be demoted back to universe or b) request all of libav's build dependencies to be promoted to main. You think any of these requests would succeed? libav can be demoted next cycle when KDE gets demoted to universe. Micah ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#658084: libav-extra: Really necessary?
On Mar 21, 2012 4:40 PM, Micah Gersten mic...@ubuntu.com wrote: On 03/21/2012 06:40 AM, Andres Mejia wrote: On Wed, Mar 21, 2012 at 2:12 AM, Reinhard Tartler siret...@gmail.com wrote: Do you volunteer to do at least the first uploads for libav and libav-extra for ubuntu as well? Yes, I'll volunteer, but the first thing I would do for ubuntu is a) request libav to be demoted back to universe or b) request all of libav's build dependencies to be promoted to main. You think any of these requests would succeed? libav can be demoted next cycle when KDE gets demoted to universe. Micah Great thanks. Reinhard, did you wanted 0.8.1 in precise? Betafreeze is tomorrow. ~ Andres ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#658084: libav-extra: Really necessary?
On Wed, Mar 21, 2012 at 12:40 PM, Andres Mejia amejia...@gmail.com wrote: On Wed, Mar 21, 2012 at 2:12 AM, Reinhard Tartler siret...@gmail.com wrote: On Wed, Mar 21, 2012 at 1:40 AM, Andres Mejia amejia...@gmail.com wrote: Here are some of the comments Reinhard said on IRC. Placing them here for recording purposes. [02:47] siretart amejia: in the merged case, I think the -dev packages can have tight dependencies on the library packages [02:48] siretart amejia: also, I think only libavcodec changes, so in that case we'd no longer need to provide e.g. libavutil-extra-51 [03:00] siretart amejia: ultimatively, I think this change goes into the right direction. unfortunately, it wont save a lot of effort, because for ubuntu we'll still need libav-extra and this change needs to be reverted there. at least for now :-( With only libavcodec having an extra package, the other extra packages would need transitional packages. Also, I'm afraid the epoch would need to be bumped again. $ dpkg --compare-versions 4:0.8.1-1 le 4:0.8.1.1 echo true true I would like to upload a package to experimental soon. Anyone have any other suggestions at this time? Do you volunteer to do at least the first uploads for libav and libav-extra for ubuntu as well? -- regards, Reinhard Yes, I'll volunteer, but the first thing I would do for ubuntu is a) request libav to be demoted back to universe or b) request all of libav's build dependencies to be promoted to main. You think any of these requests would succeed? micahg mentioned that a) is likely to happen after the precise release (which will happen end of april). -- regards, Reinhard ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#658084: libav-extra: Really necessary?
On Wed, Mar 21, 2012 at 9:55 PM, Andres Mejia amejia...@gmail.com wrote: On Mar 21, 2012 4:40 PM, Micah Gersten mic...@ubuntu.com wrote: On 03/21/2012 06:40 AM, Andres Mejia wrote: On Wed, Mar 21, 2012 at 2:12 AM, Reinhard Tartler siret...@gmail.com wrote: Do you volunteer to do at least the first uploads for libav and libav-extra for ubuntu as well? Yes, I'll volunteer, but the first thing I would do for ubuntu is a) request libav to be demoted back to universe or b) request all of libav's build dependencies to be promoted to main. You think any of these requests would succeed? libav can be demoted next cycle when KDE gets demoted to universe. Micah Great thanks. Reinhard, did you wanted 0.8.1 in precise? Betafreeze is tomorrow. Thanks for the notice, yes I did, and unfortunately, I'm travelling and won't be at home before friday. Could anyone from the team please upload 0.8.1 to precise for me before the freeze? Thanks in advance! -- regards, Reinhard ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#658084: libav-extra: Really necessary?
On 03/21/2012 05:58 PM, Reinhard Tartler wrote: Could anyone from the team please upload 0.8.1 to precise for me before the freeze? Thanks in advance! I think with the changes made to the version in 4:0.8.1-1, a merge would need an FFe if we're going to keep everything that Debian has enabled. Micah ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#658084: libav-extra: Really necessary?
On Wed, Mar 21, 2012 at 6:58 PM, Reinhard Tartler siret...@gmail.com wrote: On Wed, Mar 21, 2012 at 9:55 PM, Andres Mejia amejia...@gmail.com wrote: On Mar 21, 2012 4:40 PM, Micah Gersten mic...@ubuntu.com wrote: On 03/21/2012 06:40 AM, Andres Mejia wrote: On Wed, Mar 21, 2012 at 2:12 AM, Reinhard Tartler siret...@gmail.com wrote: Do you volunteer to do at least the first uploads for libav and libav-extra for ubuntu as well? Yes, I'll volunteer, but the first thing I would do for ubuntu is a) request libav to be demoted back to universe or b) request all of libav's build dependencies to be promoted to main. You think any of these requests would succeed? libav can be demoted next cycle when KDE gets demoted to universe. Micah Great thanks. Reinhard, did you wanted 0.8.1 in precise? Betafreeze is tomorrow. Thanks for the notice, yes I did, and unfortunately, I'm travelling and won't be at home before friday. Could anyone from the team please upload 0.8.1 to precise for me before the freeze? Thanks in advance! -- regards, Reinhard I'm not an Ubuntu developer I'm afraid. At best I could have something ready for someone to review and sponsor for an upload to Ubuntu. We could always ask for a freeze exception. After all, this new release brings a lot of security fixes. -- ~ Andres ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#658084: libav-extra: Really necessary?
On 03/21/2012 06:34 PM, Andres Mejia wrote: On Wed, Mar 21, 2012 at 6:58 PM, Reinhard Tartler siret...@gmail.com wrote: On Wed, Mar 21, 2012 at 9:55 PM, Andres Mejia amejia...@gmail.com wrote: On Mar 21, 2012 4:40 PM, Micah Gersten mic...@ubuntu.com wrote: On 03/21/2012 06:40 AM, Andres Mejia wrote: On Wed, Mar 21, 2012 at 2:12 AM, Reinhard Tartler siret...@gmail.com wrote: Do you volunteer to do at least the first uploads for libav and libav-extra for ubuntu as well? Yes, I'll volunteer, but the first thing I would do for ubuntu is a) request libav to be demoted back to universe or b) request all of libav's build dependencies to be promoted to main. You think any of these requests would succeed? libav can be demoted next cycle when KDE gets demoted to universe. Micah Great thanks. Reinhard, did you wanted 0.8.1 in precise? Betafreeze is tomorrow. Thanks for the notice, yes I did, and unfortunately, I'm travelling and won't be at home before friday. Could anyone from the team please upload 0.8.1 to precise for me before the freeze? Thanks in advance! -- regards, Reinhard I'm not an Ubuntu developer I'm afraid. At best I could have something ready for someone to review and sponsor for an upload to Ubuntu. We could always ask for a freeze exception. After all, this new release brings a lot of security fixes. Would anyone mind if I just used the new upstream version without merging? Does precise need any of the other changes made recently? ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#658084: libav-extra: Really necessary?
Here are some of the comments Reinhard said on IRC. Placing them here for recording purposes. [02:47] siretart amejia: in the merged case, I think the -dev packages can have tight dependencies on the library packages [02:48] siretart amejia: also, I think only libavcodec changes, so in that case we'd no longer need to provide e.g. libavutil-extra-51 [03:00] siretart amejia: ultimatively, I think this change goes into the right direction. unfortunately, it wont save a lot of effort, because for ubuntu we'll still need libav-extra and this change needs to be reverted there. at least for now :-( With only libavcodec having an extra package, the other extra packages would need transitional packages. Also, I'm afraid the epoch would need to be bumped again. $ dpkg --compare-versions 4:0.8.1-1 le 4:0.8.1.1 echo true true I would like to upload a package to experimental soon. Anyone have any other suggestions at this time? -- ~ Andres ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#658084: libav-extra: Really necessary?
Ok, here are the changes to libav to include libav-extra so far. Just tested these and they provide a smooth upgrade with libav/libav-extra packages currently in unstable. avconv can use either libavcodec or libavcodec-extra package and it works like it should. None of the other packages were necessary as far as I can tell. Also, libav-source will be dropped. If nobody has any other suggestions, I would like to upload this to experimental for further testing. -- ~ Andres ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#658084: libav-extra: Really necessary?
Am 19.03.2012 03:59, schrieb Andres Mejia: Though the build time is increased for libav, ultimately, this change would be better as the buildd network would not have to cope with building from two source packages (i.e. setting up and tearing down for libav and libav-extra for each architecture). Also, in my opinion, it is easier and less error prone to maintain a single libav package rather than two of them. I generally agree with your proposal, although easier and less error-prone is in the eye of the beholder, of course. At least I am currently a bit lost in your proposed diff against debian/rules. ;) In this context, please remove the libav-source binary package as well. It is of no further use (that I know of) if the libav-extra source package is removed. Also, please make sure that only the dynamic libraries are rebuilt for the extra packages, not the static one (don't know if it is already like this; as I said, the diff is a bit too much for me on a Monday morning ;) ). - Fabian ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#658084: libav-extra: Really necessary?
Am 19.03.2012 10:25, schrieb Fabian Greffrath: I generally agree with your proposal, although easier and less error-prone is in the eye of the beholder, of course. At least I am currently a bit lost in your proposed diff against debian/rules. ;) Furthermore, I think the additional debian/lib*-extra.copyright files, since they are all identical, should get created per package from a debian/copyright-extra.in template file and removed in the clean rule. - Fabian ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#658084: libav-extra: Really necessary?
On Mon, Mar 19, 2012 at 5:25 AM, Fabian Greffrath fab...@greffrath.com wrote: Am 19.03.2012 03:59, schrieb Andres Mejia: Though the build time is increased for libav, ultimately, this change would be better as the buildd network would not have to cope with building from two source packages (i.e. setting up and tearing down for libav and libav-extra for each architecture). Also, in my opinion, it is easier and less error prone to maintain a single libav package rather than two of them. I generally agree with your proposal, although easier and less error-prone is in the eye of the beholder, of course. At least I am currently a bit lost in your proposed diff against debian/rules. ;) In this context, please remove the libav-source binary package as well. It is of no further use (that I know of) if the libav-extra source package is removed. Also, please make sure that only the dynamic libraries are rebuilt for the extra packages, not the static one (don't know if it is already like this; as I said, the diff is a bit too much for me on a Monday morning ;) ). - Fabian I think the libav-source package will still be useful. There are people who like to activate/deactivate certain features of libav. They can use the libav-source package and ensure they have a build with all the patches applied for the Debian builds of libav. -- ~ Andres ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Bug#658084: libav-extra: Really necessary?
On 12-03-19 at 08:59am, Andres Mejia wrote: On Mon, Mar 19, 2012 at 5:25 AM, Fabian Greffrath fab...@greffrath.com wrote: Am 19.03.2012 03:59, schrieb Andres Mejia: Though the build time is increased for libav, ultimately, this change would be better as the buildd network would not have to cope with building from two source packages (i.e. setting up and tearing down for libav and libav-extra for each architecture). Also, in my opinion, it is easier and less error prone to maintain a single libav package rather than two of them. I generally agree with your proposal, although easier and less error-prone is in the eye of the beholder, of course. At least I am currently a bit lost in your proposed diff against debian/rules. ;) In this context, please remove the libav-source binary package as well. It is of no further use (that I know of) if the libav-extra source package is removed. Also, please make sure that only the dynamic libraries are rebuilt for the extra packages, not the static one (don't know if it is already like this; as I said, the diff is a bit too much for me on a Monday morning ;) ). I think the libav-source package will still be useful. There are people who like to activate/deactivate certain features of libav. They can use the libav-source package and ensure they have a build with all the patches applied for the Debian builds of libav. I disagree: That argument would apply for *any* package in Debian. Binary packages containing sources is a special construct specifically for our build system, not needed for direct exposure to our users: Users who want to recompile packages can much easier do so by forking the source package. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#658084: libav-extra: Really necessary?
On Mon, Mar 19, 2012 at 9:14 AM, Jonas Smedegaard d...@jones.dk wrote: On 12-03-19 at 08:59am, Andres Mejia wrote: On Mon, Mar 19, 2012 at 5:25 AM, Fabian Greffrath fab...@greffrath.com wrote: Am 19.03.2012 03:59, schrieb Andres Mejia: Though the build time is increased for libav, ultimately, this change would be better as the buildd network would not have to cope with building from two source packages (i.e. setting up and tearing down for libav and libav-extra for each architecture). Also, in my opinion, it is easier and less error prone to maintain a single libav package rather than two of them. I generally agree with your proposal, although easier and less error-prone is in the eye of the beholder, of course. At least I am currently a bit lost in your proposed diff against debian/rules. ;) In this context, please remove the libav-source binary package as well. It is of no further use (that I know of) if the libav-extra source package is removed. Also, please make sure that only the dynamic libraries are rebuilt for the extra packages, not the static one (don't know if it is already like this; as I said, the diff is a bit too much for me on a Monday morning ;) ). I think the libav-source package will still be useful. There are people who like to activate/deactivate certain features of libav. They can use the libav-source package and ensure they have a build with all the patches applied for the Debian builds of libav. I disagree: That argument would apply for *any* package in Debian. Binary packages containing sources is a special construct specifically for our build system, not needed for direct exposure to our users: Users who want to recompile packages can much easier do so by forking the source package. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers Yes, after thinking about it, I was going to draw the same conclusion. Since the libav-extra package would no longer be needed, the libav-source package should go away. Users needing a different installation of libav libs can simply download the source package and recompile with whatever options they needed. -- ~ Andres ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#658084: libav-extra: Really necessary?
Am 19.03.2012 14:38, schrieb Andres Mejia: I made the changes to filter out building of static libs for extra packages. See [1]. Note that I rebased the changes from current master, so if you checked out this branch, you'll have to merge the changes back in. Alright. In this context, has someone lately tried out if the static libs that we provide in the -dev packages work at all? ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#658084: libav-extra: Really necessary?
On Mon, Mar 19, 2012 at 9:52 AM, Fabian Greffrath fab...@greffrath.com wrote: Am 19.03.2012 14:38, schrieb Andres Mejia: I made the changes to filter out building of static libs for extra packages. See [1]. Note that I rebased the changes from current master, so if you checked out this branch, you'll have to merge the changes back in. Alright. In this context, has someone lately tried out if the static libs that we provide in the -dev packages work at all? Yes, and they do. -- ~ Andres ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#658084: libav-extra: Really necessary?
Am 19.03.2012 15:27, schrieb Andres Mejia: Yes, and they do. Good to know, thanks! ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#658084: libav-extra: Really necessary?
Here is what I propose in order to provide the lib*extra* packages from the libav source package. [1] It essentially has libav building the extra packages, thus no longer having to rely on a seperate source package. This change ensures the regular and the extra packages are built for all 'flavors' to be built depending on the architecture. As I said before, as far as building the GPLv3 enabled libraries, there is no reason to do that with a seperate source package. Building them separately would not change the fact that the packages are ultimately distributed through Debian main. The source package will remain LGPLv2.1+. The binaries will be GPLv2+ for the regular packages, and GPLv3+ for the extra packages. Though the build time is increased for libav, ultimately, this change would be better as the buildd network would not have to cope with building from two source packages (i.e. setting up and tearing down for libav and libav-extra for each architecture). Also, in my opinion, it is easier and less error prone to maintain a single libav package rather than two of them. 1. http://anonscm.debian.org/gitweb/?p=pkg-multimedia/libav.git;a=commitdiff;h=3037cab27717de75a73c77a553ab6dfad04a57da;hp=d78d2e6d0d0f43a6203ee6b78a8c0fefcab7838a -- ~ Andres ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Bug#658084: libav-extra: Really necessary?
Am 03.02.2012 17:11, schrieb Reinhard Tartler: Well, having all packages (with tightened dependencies) is more convinient for the users if libav and libav-extra become out-of-sync. If out-of-sync means ABI-incompatible, then the other -extra packages won't help anyway. Would you accept a patch against libav-extra that changes it to only build (all flavors of) libavcodec and change the Conflicts of the other libraries to Depends? So that e.g. libswscale-extra-2 would depend on the (identical) libswscale2 instead of conflicting against it. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Bug#658084: libav-extra: Really necessary?
On Mon, Feb 6, 2012 at 2:43 PM, Fabian Greffrath fab...@greffrath.com wrote: Am 03.02.2012 17:11, schrieb Reinhard Tartler: Well, having all packages (with tightened dependencies) is more convinient for the users if libav and libav-extra become out-of-sync. If out-of-sync means ABI-incompatible, then the other -extra packages won't help anyway. Would you accept a patch against libav-extra that changes it to only build (all flavors of) libavcodec and change the Conflicts of the other libraries to Depends? So that e.g. libswscale-extra-2 would depend on the (identical) libswscale2 instead of conflicting against it. What problem would this solve? -- regards, Reinhard ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Bug#658084: libav-extra: Really necessary?
Am 06.02.2012 14:48, schrieb Reinhard Tartler: What problem would this solve? Reducing complexity, avoiding redundant building of identical code, stopping to pretend any -extra flavor apart from libavcodec would be different to the regular non-extra lib. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Bug#658084: libav-extra: Really necessary?
On Mon, Feb 6, 2012 at 3:45 PM, Fabian Greffrath fab...@greffrath.com wrote: Am 06.02.2012 14:48, schrieb Reinhard Tartler: What problem would this solve? Reducing complexity, really? AFAIUI, it would make the diff between the two debian/rules files larger, which makes it harder to cherry pick changes avoiding redundant building of identical code, stopping to pretend any -extra flavor apart from libavcodec would be different to the regular non-extra lib. These appear more like cosmetical issue rather than bringing actual benefits to our users nor actually helping maintenance. -- regards, Reinhard ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Bug#658084: libav-extra: Really necessary?
Am 01.02.2012 16:25, schrieb Reinhard Tartler: The proposal doesn't allow me to drop libav-extra in Ubuntu. This means, that 'libav' in Ubuntu/main must not provide libavcodec-extra-53. In this context, it is really necessary for libav-extra to build *all* packages and not only libavcodec-extra-53? I mean, e.g. libswscale and libpostproc should be pretty unimpressed by a handful of enabled codecs. ;) ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Bug#658084: libav-extra: Really necessary?
On Fri, Feb 3, 2012 at 4:28 PM, Fabian Greffrath fab...@greffrath.com wrote: Am 01.02.2012 16:25, schrieb Reinhard Tartler: The proposal doesn't allow me to drop libav-extra in Ubuntu. This means, that 'libav' in Ubuntu/main must not provide libavcodec-extra-53. In this context, it is really necessary for libav-extra to build *all* packages and not only libavcodec-extra-53? I mean, e.g. libswscale and libpostproc should be pretty unimpressed by a handful of enabled codecs. ;) Well, having all packages (with tightened dependencies) is more convinient for the users if libav and libav-extra become out-of-sync. -- regards, Reinhard ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Bug#658084: libav-extra: Really necessary?
Am 31.01.2012 17:55, schrieb Reinhard Tartler: On Tue, Jan 31, 2012 at 5:44 PM, Jonas Smedegaardd...@jones.dk wrote: Problem is that other packages can carefully ensure not violating licensing when linking against libav, and libav-extra then distorts that by causing Debian as a whole to not ensure against same violation. Yes, that's it. Thanks for finding clear words, Jonas. ;) How about having libav-extra package conflict with other packages known to not be compatible with the tighter licensing? That would be an option. Another option would be to have those packages declare a conflicts on libav-extra. nit: wouldn't the breaks relationship be more appropriate here? Yes, sure. No need to deconfigure offending packages, it should be enough to make sure they are not installed at the same time. I don't think we should overdo the license-policy game. If we become aware of a license clash, we can add a conflict, as Jonas suggest. This leads us to the next question (the one I meant with analysis): Do we already *know* of license clashes of specific software with a GPL-v3 licensed libav? Or is the whole introduction of libav-extra done for precaution? How is this handled in the gstreamer packages? I see that gst-plugins-ugly0.10 is linked against the apache-2.0 licensed libopencore-amrwb0 and is still distributed under the terms of the LGPL-2.0+. Legally, I don't think there is much difference here. However, there is a practical difference for Debian as distribution: we do not violate the packages if users install a combination of packages that result to a license clash. Yes, we can add conflicts, and probably have to if we become aware of it, but we cannot be held responsible for funky stuff that random users do on their (own) systems. Reminds me of the libcurl situation. We have both libcurl (linked against openssl) and libcurl-gnutls packages in Debian. The latter is for packages with licenses incompatible to openssl's one. However, nothing prevents you from installing the openssl-linked libcurl package on your system if you wish so. What parts of libav are actually affected by the two additional codecs? I guess it's only libavcodec (and maybe libavformat). If it really boils down to rebuild only one library with aditional confflags, I begin to like Andres' idea more and integrate libav-extra into the libav package. - Fabian ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Bug#658084: libav-extra: Really necessary?
On 12-02-01 at 10:24am, Fabian Greffrath wrote: Am 31.01.2012 17:55, schrieb Reinhard Tartler: Legally, I don't think there is much difference here. However, there is a practical difference for Debian as distribution: we do not violate the packages if users install a combination of packages that result to a license clash. Yes, we can add conflicts, and probably have to if we become aware of it, but we cannot be held responsible for funky stuff that random users do on their (own) systems. Reminds me of the libcurl situation. We have both libcurl (linked against openssl) and libcurl-gnutls packages in Debian. The latter is for packages with licenses incompatible to openssl's one. However, nothing prevents you from installing the openssl-linked libcurl package on your system if you wish so. I believe multiple flavors of libcurl is installable concurrently, which means dependent packages can link against a specific one as licensing requires. With libav you provide no way for dependent packages to ensure their licensing is respected. What parts of libav are actually affected by the two additional codecs? I guess it's only libavcodec (and maybe libavformat). If it really boils down to rebuild only one library with aditional confflags, I begin to like Andres' idea more and integrate libav-extra into the libav package. If ok legally then certainly that's most elegant. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Bug#658084: libav-extra: Really necessary?
On Wed, Feb 1, 2012 at 11:49 AM, Jonas Smedegaard d...@jones.dk wrote: On 12-02-01 at 10:24am, Fabian Greffrath wrote: Am 31.01.2012 17:55, schrieb Reinhard Tartler: Legally, I don't think there is much difference here. However, there is a practical difference for Debian as distribution: we do not violate the packages if users install a combination of packages that result to a license clash. Yes, we can add conflicts, and probably have to if we become aware of it, but we cannot be held responsible for funky stuff that random users do on their (own) systems. Reminds me of the libcurl situation. We have both libcurl (linked against openssl) and libcurl-gnutls packages in Debian. The latter is for packages with licenses incompatible to openssl's one. However, nothing prevents you from installing the openssl-linked libcurl package on your system if you wish so. I didn't check the curl situation, but yes, that sounds a bit similar. I believe multiple flavors of libcurl is installable concurrently, which means dependent packages can link against a specific one as licensing requires. With libav you provide no way for dependent packages to ensure their licensing is respected. What parts of libav are actually affected by the two additional codecs? I guess it's only libavcodec (and maybe libavformat). Well, in detail, it affects two additional build dependencies, which are then detected at build time if present by debian/confflags. These enable the respective library wrappers. If it really boils down to rebuild only one library with aditional confflags, I begin to like Andres' idea more and integrate libav-extra into the libav package. If ok legally then certainly that's most elegant. Sorry, I disagree with that approach. It a) increases the complexity of the packaging considerably, b) doubles the build-times and c) doesn't help at all with keeping the diff for ubuntu minimal. -- regards, Reinhard ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Bug#658084: libav-extra: Really necessary?
Am 01.02.2012 16:02, schrieb Reinhard Tartler: Sorry, I disagree with that approach. It a) increases the complexity of the packaging considerably, b) doubles the build-times and c) doesn't help at all with keeping the diff for ubuntu minimal. Well, I think that's debatable. Having two separate source package for the sake of two additional codecs could also be considered as increased complexity. And if I understand it right, it's only libavcodec that needs to get rebuilt with a slightly different set of confflags, i.e. the ones that enable the codecs in question. These could be set to different values (i.e. different additional codecs) depending if the package is built for Debian or Ubuntu. ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Bug#658084: libav-extra: Really necessary?
On Feb 1, 2012 10:03 AM, Reinhard Tartler siret...@gmail.com wrote: On Wed, Feb 1, 2012 at 11:49 AM, Jonas Smedegaard d...@jones.dk wrote: On 12-02-01 at 10:24am, Fabian Greffrath wrote: Am 31.01.2012 17:55, schrieb Reinhard Tartler: Legally, I don't think there is much difference here. However, there is a practical difference for Debian as distribution: we do not violate the packages if users install a combination of packages that result to a license clash. Yes, we can add conflicts, and probably have to if we become aware of it, but we cannot be held responsible for funky stuff that random users do on their (own) systems. Reminds me of the libcurl situation. We have both libcurl (linked against openssl) and libcurl-gnutls packages in Debian. The latter is for packages with licenses incompatible to openssl's one. However, nothing prevents you from installing the openssl-linked libcurl package on your system if you wish so. I didn't check the curl situation, but yes, that sounds a bit similar. I believe multiple flavors of libcurl is installable concurrently, which means dependent packages can link against a specific one as licensing requires. With libav you provide no way for dependent packages to ensure their licensing is respected. What parts of libav are actually affected by the two additional codecs? I guess it's only libavcodec (and maybe libavformat). Well, in detail, it affects two additional build dependencies, which are then detected at build time if present by debian/confflags. These enable the respective library wrappers. If it really boils down to rebuild only one library with aditional confflags, I begin to like Andres' idea more and integrate libav-extra into the libav package. If ok legally then certainly that's most elegant. Sorry, I disagree with that approach. It a) increases the complexity of the packaging considerably, I find it more complex and error prone to maintain two libav packages than one. b) doubles the build-times The current situation still does this, only it's worse. The buildd machines have to perform the setup and cleanup twice for the two source packages on top of building the two packages. and c) doesn't help at all with keeping the diff for ubuntu minimal. Why is libav in ubuntu main anyway? Shouldn't it be in universe still, particularly because most dependencies are in universe/multiverse? How about if another name for the *-extra libs is used, like *-gpl3 for example? -- regards, Reinhard ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers ~ Andres ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Bug#658084: libav-extra: Really necessary?
On Wed, Feb 1, 2012 at 4:15 PM, Fabian Greffrath fab...@greffrath.com wrote: Am 01.02.2012 16:02, schrieb Reinhard Tartler: Sorry, I disagree with that approach. It a) increases the complexity of the packaging considerably, b) doubles the build-times and c) doesn't help at all with keeping the diff for ubuntu minimal. Well, I think that's debatable. Having two separate source package for the sake of two additional codecs could also be considered as increased complexity. It's the status quo. And I don't believe that the implementation of what you guys propose will be any less complex than what we currently have. And if I understand it right, it's only libavcodec that needs to get rebuilt with a slightly different set of confflags, i.e. the ones that enable the codecs in question. These could be set to different values (i.e. different additional codecs) depending if the package is built for Debian or Ubuntu. The proposal doesn't allow me to drop libav-extra in Ubuntu. This means, that 'libav' in Ubuntu/main must not provide libavcodec-extra-53. And now things start to become way to complex for me to think further about it. Sorry, but no thanks. -- regards, Reinhard ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Re: Bug#658084: libav-extra: Really necessary?
On Wed, Feb 1, 2012 at 4:24 PM, Andres Mejia amejia...@gmail.com wrote: I find it more complex and error prone to maintain two libav packages than one. b) doubles the build-times The current situation still does this, only it's worse. The buildd machines have to perform the setup and cleanup twice for the two source packages on top of building the two packages. and c) doesn't help at all with keeping the diff for ubuntu minimal. Why is libav in ubuntu main anyway? Shouldn't it be in universe still, particularly because most dependencies are in universe/multiverse? IIRC there are still some KDE parts in main that depend on libav. If we could get libav demoted, that would indeed make things easier, regardless what we decide here. How about if another name for the *-extra libs is used, like *-gpl3 for example? That would require to rebuild the archive again to pick up the new shlibs. Would probably take at least a release cycle. -- regards, Reinhard ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#658084: libav-extra: Really necessary?
Package: libav-extra Severity: wishlist Dear Reinhard et at, I'd like to start a discussion about this package by means of this bug report. Honestly, I do not see the purpose of this package and while I appreciate the work Reinhard has done with it, am not sure where it will bring us. First, as pointed out in 653451, this package offers merely two additional codecs compared to the regular libav packages. One is a (redundant?) AAC encoder and the other one is an AMR-WB encoder. Quite exotic if you are asking me. I'd say, if you really need these codecs, rebuild the libav package - it's all in the archive. Second, the reason why these codecs are not enabled in the standard libav package is AFAIUI their licensing, which would require the GPL-v3 to apply for the whole of the libav libraries - in contrast to GPL-v2+ without these codecs. This might lead to some legal problems when linking with software licensed under GPL-v3-incompatible terms (right?). However, I think what we are doing with libav-extra is a bit insincere. We pretend to play fair by only building packages against the GPL-v2+ libav libraries but then offer the possibly license-incompatible GPL-v3 libraries from the libav-extra packages for runtime linking. TL;DR I think we should either enable the additional codecs in the regular libav package, accept the license bump and analyze the license problems that might occur with other packages. Or we should accept the fact that there are potential license problems and disable these two offending codecs altogether. The current solution with two libav* packages is not a stright line IMHO. Cheers, Fabian -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (901, 'testing'), (501, 'unstable'), (101, 'experimental') Architecture: i386 (i686) Kernel: Linux 3.1.0-1-686-pae (SMP w/1 CPU core) Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#658084: libav-extra: Really necessary?
Am 31.01.2012 16:30, schrieb Reinhard Tartler: I still fail to see what the problem is. I understand that you don't like the approach, but maybe you can elaborate on the 'insencere' or 'not straight' part. Yes, I'll try. AFAIUI there are packages out there that use libav libraries but for which licenses apply that are incompatible with GPL-v3. In order to not violate these licenses when building or run-time linking against libav libraries, we have disabled the offending codecs that cause the license change. On the other hand we have a libav-extra package with libraries for which GPL-v3 applies and which thus violate the license terms of said software if it is linked against it. So the whole purpose of the libav-extra package seems to be to tolerate license clashes at runtime while playing fair at build time with the regular libav package. I hope I made myself clearer, hm. - Fabian ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#658084: libav-extra: Really necessary?
Am 31.01.2012 17:13, schrieb Fabian Greffrath: I hope I made myself clearer, hm. We do not build packages against libav-extra, i.e. no build-time linking. Reason: Possible license clashes with GPL-v3. We offer libav-extra for run-time linking: What about license clashes here? Do I misinterpret/mess up the (legal) difference/meaning of build-time and run-time linking? ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#658084: libav-extra: Really necessary?
On 12-01-31 at 04:30pm, Reinhard Tartler wrote: On Di, Jan 31, 2012 at 10:37:23 (CET), Fabian Greffrath wrote: I think what we are doing with libav-extra is a bit insincere. We pretend to play fair by only building packages against the GPL-v2+ libav libraries but then offer the possibly license-incompatible GPL-v3 libraries from the libav-extra packages for runtime linking. So why is that insincere? What's the problem with that? Problem is that other packages can carefully ensure not violating licensing when linking against libav, and libav-extra then distorts that by causing Debian as a whole to not ensure against same violation. How about having libav-extra package conflict with other packages known to not be compatible with the tighter licensing? - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#658084: libav-extra: Really necessary?
On Tue, Jan 31, 2012 at 5:44 PM, Jonas Smedegaard d...@jones.dk wrote: On 12-01-31 at 04:30pm, Reinhard Tartler wrote: On Di, Jan 31, 2012 at 10:37:23 (CET), Fabian Greffrath wrote: I think what we are doing with libav-extra is a bit insincere. We pretend to play fair by only building packages against the GPL-v2+ libav libraries but then offer the possibly license-incompatible GPL-v3 libraries from the libav-extra packages for runtime linking. So why is that insincere? What's the problem with that? Problem is that other packages can carefully ensure not violating licensing when linking against libav, and libav-extra then distorts that by causing Debian as a whole to not ensure against same violation. How about having libav-extra package conflict with other packages known to not be compatible with the tighter licensing? That would be an option. Another option would be to have those packages declare a conflicts on libav-extra. nit: wouldn't the breaks relationship be more appropriate here? -- regards, Reinhard ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
Bug#658084: libav-extra: Really necessary?
On Tue, Jan 31, 2012 at 5:24 PM, Fabian Greffrath fab...@greffrath.com wrote: Am 31.01.2012 17:13, schrieb Fabian Greffrath: I hope I made myself clearer, hm. We do not build packages against libav-extra, i.e. no build-time linking. Reason: Possible license clashes with GPL-v3. We offer libav-extra for run-time linking: What about license clashes here? I don't think we should overdo the license-policy game. If we become aware of a license clash, we can add a conflict, as Jonas suggest. Do I misinterpret/mess up the (legal) difference/meaning of build-time and run-time linking? Legally, I don't think there is much difference here. However, there is a practical difference for Debian as distribution: we do not violate the packages if users install a combination of packages that result to a license clash. Yes, we can add conflicts, and probably have to if we become aware of it, but we cannot be held responsible for funky stuff that random users do on their (own) systems. -- regards, Reinhard ___ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers
