On Mon, Jul 07, 2014 at 09:14:44PM +0200, Johannes Schauer wrote: > Quoting Steve Langasek (2014-07-07 20:22:42) > > Ah. No, it only means that the package build does not *fail* if the > > build-dependency is removed. That is not the same thing as saying that the > > build-dependency is not used. > you are correct. I expanded more on this in my other reply to Don Armstrong. > > It would of course be better if packages were resilient against breakage in > > their build-dependencies, instead of misbuilding with features disabled or > > with wrong fallback code. But this isn't easy to do in all build systems, > > and anyway this isn't something we routinely audit about our packages; we > > shouldn't regard this as a bug to be reported without a lot more discussion > > of how we're going to systematically stay on top of those issues in the > > future. > I agree that it should not be a bug if a package does not fail if a certain > build dependency is not installed. > Nevertheless, those "false positives" that were generated this way are still > useful to be later marked with <!profile.stage1> once build profiles are > allowed in the archive because they are obviously droppable. No, marking build-dependencies with build profiles should be driven by what is needed to break build-dep loops, not by what build-deps are "droppable" without further modification of the packages. Excessive stage1 profile tagging will result in unnecessary extra builds during a bootstrap. > I did not plan to run this script more often yet. I'll probably do another > run after having added a detection for meta packages as suggested by you > below. > Running it more regularly might not require any big discussion because the > "problem size" might be small enough that maintaining a white list would be > enough. If you really want to systematically detect misbuilds on missing build-dependencies, it's a much bigger problem than just detecting this for the build-dependencies which are metapackages. In my personal opinion, this is not worth doing. But if you are going to do it, be comprehensive - anything less than that is counterproductive. > > For your purposes, a better method would be: > > - identify those build-dependencies which are empty except for > > /usr/share/doc > > - for each such package, look at the contents of its direct dependencies > > - check the build against those contents > While this would often work it would still miss some meta packages which > do ship some more files than /usr/share/doc but are otherwise mostly > important because of the packages they depend on. Though I guess this > would already tremendously decrease the amount of false positive (however > high their number is) and I should implement that for the next time I > recalculate this. There certainly will be other cases that this technique won't cover, but it won't cause any false-negatives for your purposes. I don't know what the numbers will look like overall, but 3 out of 4 packages listed by my name were false-positives that can be filtered out this way, so I definitely think it's worth a rerun before MBF. > > For the case of pam, I would be interested in seeing the full build log to > > understand how in the world this built successfully without libdb. That's > > definitely a packaging error on my part, because without libdb, pam_userdb.so > > should not build, which in turn *should* be treated as a build failure. But > > I guess I'm not accounting for individual modules in the build output, since > > in general the greater risk is failing to keep this list in sync with new > > upstream modules, rather than misbuilding and losing a module from the tree. > Sorry, I already deleted my chroot :( No worries... as previously suggested this is not high on my priority list ;) -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slangasek@ubuntu.com vorlon@debian.org
Attachment:
signature.asc
Description: Digital signature