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

Re: possible MBF: automatically detecting unused build dependencies

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

Reply to: