[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: possible MBF: automatically detecting unused build dependencies



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


Reply to: