Hi, 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. About "systematically staying on top of those issues" I do not know how to proceed. I guess for that we would first need to know how many source packages depend on meta packages which are not completely empty (besides /usr/share/doc) and still silently fail and continue building with reduced features. 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. > 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. > 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 :( cheers, josch -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140707191444.14505.34985@hoothoot
