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 ? > 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. Regis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
