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 [cjwatson@debian.org]
Reply to: