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
Bug#731526: ITP: radosgw-agent -- Synchronize data and users between radosgw clusters
Package: wnpp Severity: wishlist Owner: James Page * Package name: radosgw-agent Version : 1.1 * URL : http://github.com/ceph/radosgw-agent * License : MIT Programming Lang: Python Description : Synchronize data and users between radosgw clusters RADOS is a distributed object store used by the Ceph distributed storage system. The RADOS Gateway provides a RESTful gateway to the object store that aims to implement a superset of Amazon's S3 service . This package contains the agent for synchronization between geographically separated RADOS Gateway deployments. This package will be maintained by the pkg-ceph team. -- 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/20131206095551.5595.26367.reportbug@armstrong.shouse.local
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 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 wrote: > On 2013-12-06, Thorsten Glaser 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 -- 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
Bug#731554: ITP: liblwp-authen-oauth2-perl -- Make requests to OAuth2 APIs from Perl
Package: wnpp Severity: wishlist Owner: Alexander Dutton * Package name: liblwp-authen-oauth2-perl Version : 0.07 Upstream Author : Ben Tilly * URL : https://github.com/btilly/perl-oauth2 * License : Artistic Programming Lang: Perl Description : Make requests to OAuth2 APIs from Perl LWP::Authen::OAuth2 lets you access OAuth 2 protected APIs with LWP. Specifically it provides helper methods to construct all requests to the service provider, and takes care (if possible) of details like automatically refreshing tokens when needed. -- 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/20131206151529.7431.93077.reportbug@cud-dev
Re: IPMI/LOM/DRAC/ILO/etc. (was Re: Release sprint results - team changes, auto-rm and arch status)
On Thu, 5 Dec 2013 14:32:32 +0100 (CET), Thorsten Glaser wrote: >On Wed, 4 Dec 2013, Tollef Fog Heen wrote: > >> Does it have IPMI, LOM/DRAC/ILO/some sort of remote management or is all >> that serial console + networked power switch? I suspect Debian would be > >Isn’t “serial console + networked power switch” preferable? > >See http://fish2.com/ipmi/ (“IPMI: Freight Train to Hell”, >in case someone already read it, but it seems a new version, >PDF-only for now, is out). > >What about the “firm”ware (software) running on these >embedded devices? Should it not be replaced with Debian, too? The software on the networked power switch might suffer from the same flaws, and a networked power switch doesn't help if the device doesn't come on with the power for some reason. Greetings Marc, who prefers built-in OOB management if it's on a dedicated Ethernet -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834 -- 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/e1vp1cw-0003yn...@swivel.zugschlus.de
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 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
