On Tue, Apr 24, 2007 at 05:34:20PM +0100, Regis Boudin wrote: > On Tue, April 24, 2007 15:42, Steve Langasek wrote: > >> I have results I will put online as soon as I convert them in a better > >> format than a simple text list, but if you have comments on what to do > >> with this list, they are more than welcome.
> > In the general case: nothing. It is *not* correct to turn this into an > > alternative Build-Depends: real-package | virtual package, because sbuild > > will only look at the first branch of any or'ed build-dep. If the virtual > > package is the stable name for the -dev interface, that's what packages > > should be build-depending on. > Sure, don't misunderstand me, I'm not asking for modifying all these > packages and I certainly have no intention of filing 600+ bugs for that > :). It's only something I noticed and thought it might be interesting to > have a look at. > I totally agree with the build-depend on the stable name of the -dev > interface. However, sometimes it looks a bit strange or seems to lack some > information. Say libpng12-dev, for which there are 3 different virtual > packages (libpng-dev, libpng3-dev, libpng12-0-dev). Or libz-dev, for which > I couldn't find any documentation, even in the zlib source package, apart > from the fact that zlib1g-dev provides it. And what is the point in > build-depending on c++-compiler ? Heh, build-depending on c++-compiler is certainly a bug, yes, since g++ is covered by build-essential. For the others, despite being somewhat distracting, they aren't bugs unless the maintainer of one of those packages intends to drop the virtual package name; which unfortunately may be difficult to foresee in advance because the status quo of library maintenance in Debian isn't very good, but that just means that we might have to file the bugs after the change, not that we should start filing misleading bugs on other packages just in case. > > The reason depending on a virtual package without first listing a real > > package is considered a bug is that it gives undefined behavior in the > > selection of a package when there is more than one package providing the > > named virtual package. But there are cases where depending on the virtual > > package alone is still correct -- e.g., apt Provides: > > libapt-pkg-libc6.3-6-3.11, which is the right virtual package to depend on > > when using libapt. The same applies to build-deps on virtual packages, > > which normally are provided by only one real package at a time in a given > > suite. > I'm not saying it's bad, only bringing the subject to see if anyone finds > something interesting in it. Considering this sort of thing gives a > warning with lintian, I might as well not keep it for myself. > In any case, I will try to have these checks run daily, even if as purely > informative data. Ok. For my part, I don't find them useful, because the bugginess of build-depending on any particular virtual package must be determined on a per-package basis and usually with the assistance of the package maintainer, so it's targetted checks for individual build-dependencies that are ultimately needed. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
