Re: virtual/alternative B-D (was Re: libtiff5 transition)
On 06/12/13 20:48, Philipp Kern wrote: So if you version your -dev package, do not install into an unversioned place like libtiff5-dev does. :) It seems to me that the good options are: * one unversioned -dev package, on the default gcc include path and/or relying on pkg-config to get the appropriate -I options (good for upstreams who break API in minor ways somewhat frequently, so most depending projects will just need a binNMU, like libgnome-desktop) * n parallel-installable versioned -dev packages, *not* on the default include path, using pkg-config to get the appropriate -I options (good for upstreams who save up API breaks to do less frequent, more major changes, like Gtk 2 - 3) For the second case, if an upstream installs to /usr/include/libfoo-4/foo.h I suppose they could expect library users to #include libfoo-4/foo.h... but that guarantees that source changes will be needed for every API break, even if the subset of the API used by the application has not actually changed (whereas changing the pkg-config filename for parallel-installable versions just needs a one-line change in configure.ac or equivalent). pkg-config is useful in other situations too (version-checking, installation into a non-default prefix, etc.) and .pc files are easy to provide, so I think it should be considered best-practice for upstreams to provide .pc files for all libraries. S -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52a316bf.3010...@debian.org
virtual/alternative B-D (was Re: libtiff5 transition)
On Thu, 5 Dec 2013, Jay Berkenbilt wrote: * If your package build-depends on libtiff5-dev, you don't HAVE to do anything, but you may be helping yourself in the future if you change the build dependency to libtiff-dev ( 4.0.3-6~). Uhm, I have a rather general question here. libtiff-dev is a virtual package (it’s only provided by others). Asides from the issue of virtual packages and versioning, I’ve had ftpmasters REJECT a package of mine in NEW when it had a Build-Depends on a virtual package (libncurses-dev, which I had to change to “libncurses5-dev | libncurses-dev” first, and “libtinfo-dev | libncurses-dev” now that libtinfo is in the archive). I thought we’re supposed to not build-depend on virtual packages, especially not as first alternative? On the other hand, I totally do not understand *how* this can possibly work, given that buildd only uses the first alternative in Build-Depends anyway. (So basically, why (except for backports) bother having alternative B-D in packages at all?) I fail to see the reason behind all this; can someone explain why both the “don’t depend on virtual packages” rule seems to be in effect (although apparently only for NEW, never checked later) and buildd does not use alternatives (never got that one)? Thanks, //mirabilos -- [16:04:33] bkix: veni vidi violini [16:04:45] bkix: ich kam, sah und vergeigte... -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/alpine.deb.2.10.1312061014020.19...@tglase.lan.tarent.de
Re: virtual/alternative B-D (was Re: libtiff5 transition)
On Fri, Dec 06, 2013 at 10:19:14AM +0100, Thorsten Glaser wrote: On Thu, 5 Dec 2013, Jay Berkenbilt wrote: * If your package build-depends on libtiff5-dev, you don't HAVE to do anything, but you may be helping yourself in the future if you change the build dependency to libtiff-dev ( 4.0.3-6~). This won't work as libtiff-dev is virtual. Uhm, I have a rather general question here. libtiff-dev is a virtual package (it’s only provided by others). Asides from the issue of virtual packages and versioning, I’ve had ftpmasters REJECT a package of mine in NEW when it had a Build-Depends on a virtual package (libncurses-dev, which I had to change to “libncurses5-dev | libncurses-dev” first, and “libtinfo-dev | libncurses-dev” now that libtinfo is in the archive). I thought we’re supposed to not build-depend on virtual packages, especially not as first alternative? This rule makes sense when there are multiple providers of a virtual package: in that case a real alternative is necessary to get deterministic results. However, libtiff-dev should only ever have one provider. In this case I don't think there should be a problem; it's effectively a lightweight alternative to Package: libtiff-dev Depends: libtiff5-dev. I strongly feel that it would be detrimental to have everyone go around writing libtiff5-dev | libtiff-dev everywhere. Much better to have the default be in as few places as possible, so that the transition can be done with binNMUs. -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131206105641.ga5...@riva.ucam.org
Re: virtual/alternative B-D (was Re: libtiff5 transition)
On 06/12/13 10:56, Colin Watson wrote: On Fri, Dec 06, 2013 at 10:19:14AM +0100, Thorsten Glaser wrote: On Thu, 5 Dec 2013, Jay Berkenbilt wrote: * If your package build-depends on libtiff5-dev, you don't HAVE to do anything, but you may be helping yourself in the future if you change the build dependency to libtiff-dev ( 4.0.3-6~). This won't work as libtiff-dev is virtual. Does this imply that libtiff-dev should be a non-virtual, empty dummy/dependency package, built by, and depending on, the currently favoured version of tiff? If a virtual package can't have multiple implementors, then it looks remarkably similar to a non-virtual package. (Or libtiff-dev could be non-empty, and libtiff5-dev empty or virtual.) As far as I can see, changing from (libtiffN-dev Provides libtiff-dev, libtiff(N+1)-dev does not) to the other way round has an inherent race condition: either there'll be a brief window in which the archive contains two providers of libtiff-dev (non-deterministic builds), or a brief window in which the archive contains no provider of libtiff-dev (FTBFS for everything depending on libtiff-dev). Perhaps this doesn't matter in practice because that time is short, I don't know. S -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52a1d73f.9010...@debian.org
Re: virtual/alternative B-D (was Re: libtiff5 transition)
Simon McVittie wrote: As far as I can see, changing from (libtiffN-dev Provides libtiff-dev, libtiff(N+1)-dev does not) to the other way round has an inherent race Hm indeed. Makes me wonder whether it would not be better to make libtiff-dev the real package and abandon libtiffN-dev altogether. (Never understood why the -dev packages need the numbers, anyway.) On the other hand, that would mean that the transition starts as soon as the source package building libtiff(N+1) brings with it its own version of libtiff-dev⦠needs more careful uploads. bye, //mirabilos -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/l7slog$ege$1...@ger.gmane.org
Re: virtual/alternative B-D (was Re: libtiff5 transition)
On 2013-12-06, Thorsten Glaser t...@debian.org wrote: Hm indeed. Makes me wonder whether it would not be better to make libtiff-dev the real package and abandon libtiffN-dev altogether. (Never understood why the -dev packages need the numbers, anyway.) The -dev packages needs numbers if you want to have several around at the same time. Having the unversioned -dev package be a virtual package worksr fine as long as 1) no one will need a versioned dependency on the unversioned virtual dev package 2) only one package is providing the virtual package at a time. Yes. 2) is theoretically racy. but from a practical purpose, the race is irrelevant. /Sune -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/slrnla3oc2.j8.nos...@sshway.ssh.pusling.com
Re: virtual/alternative B-D (was Re: libtiff5 transition)
Sune Vuorela nos...@vuorela.dk wrote: On 2013-12-06, Thorsten Glaser t...@debian.org wrote: Hm indeed. Makes me wonder whether it would not be better to make libtiff-dev the real package and abandon libtiffN-dev altogether. (Never understood why the -dev packages need the numbers, anyway.) The -dev packages needs numbers if you want to have several around at the same time. My original proposal to debian-release was to drop libtiff4-dev and libtiff5-dev completely and to change the name of libtiff5-dev to libtiff-dev, but this makes it too hard to actually do the transition because too many packages become FTBFS for too long. You can see my original suggestion and subsequent discussion in bug 717923. Sorry about the suggestion to build-depend on a versioned virtual package. When we changed what the package was being called, I forgot to update that in my notes of what I was going to say. Many months elapsed between the original discussion and the uploads, and I just forgot about that detail. I think it would be best for people to avoid versioned dependencies on libtiff*-dev. The only reason to do it might be as a hint to backporters that they can't backport to a version of debian that doesn't have a libtiff5-dev alternative available to it. I think it would be best to just change all the build dependencies to libtiff-dev, but package maintainers and/or backporters should probably know what to do in those relatively rare cases where tiff 4.x is required. Most of those cases are going to GIS and similar applications, some of which may be using libgeotiff anyway, since that's where BIGTIFF is especially needed. Other packages, like vips (which I also happen to maintain), will detect with ./configure whether a tiff 4.x is in use and will use new functionality if available but will fall back if not. So if someone backported vips and ended up using a tiff 3.x version, they'd get a working package without BIGTIFF support. Perhaps after the dust settles and tiff3 is gone, I can rename libtiff5-dev to libtiff-dev, but that would break packages with versioned dependencies on libtiff5-dev and not provide much more than aesthetic benefit, so I'm not sure that it's worth it. -- Jay Berkenbilt q...@debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131206101706.0942190878.qww314...@jberkenbilt-linux.appiancorp.com
Re: virtual/alternative B-D (was Re: libtiff5 transition)
On Fri, Dec 06, 2013 at 02:38:47PM +, Sune Vuorela wrote: On 2013-12-06, Thorsten Glaser t...@debian.org wrote: Hm indeed. Makes me wonder whether it would not be better to make libtiff-dev the real package and abandon libtiffN-dev altogether. (Never understood why the -dev packages need the numbers, anyway.) The -dev packages needs numbers if you want to have several around at the same time. Also there are actually two cases: In the first one the include dir is actually versioned and the two -dev packages are coinstallable. In the second one you just select a newer (or older) version of the API and it lives in the same place. Here both packages will provide the same files and hence conflict with eachother. The second one is so much fun as you can have two packages in the build-dependency tree that need (by hardcoded Build-Depends declaration) different -dev packages and are hence not co-installable. So if you version your -dev package, do not install into an unversioned place like libtiff5-dev does. :) Kind regards Philipp Kern signature.asc Description: Digital signature
