Re: possible MBF: automatically detecting unused build dependencies
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
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
> For your purposes, a better method would be:
> - identify those build-dependencies which are empty except for
> - 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 :(