Re: possible MBF: automatically detecting unused build dependencies
Hi,
Quoting Steve Langasek (2014-07-08 00:07:29)
> On Mon, Jul 07, 2014 at 09:14:44PM +0200, Johannes Schauer wrote:
> > 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.
Bootstrapping should not get into the way of the normal packaging. There should
be strong reasons before a disruptive patch is applied to make a package build
with fewer build dependencies. This class of cases that is found by this script
(and it could be abused to find even more by omitting the first phase) sounds
to me as if only trivial changes were needed to build the package with fewer
build dependencies. Thus in case the maintainer does not have any strong
objections, there is no harm applying them.
The downside you list "unnecessary extra builds" are easy to avoid in practice.
Botch contains algorithms to find a close to minimum set of source packages to
modify to make a dependency graph acyclic (a feedback vertex set). Even if all
source packages in the dependency graph had removable build dependencies it
would only choose a small set of them (currently 60-70 are needed) to actually
build with a stage1 profile active.
Furthermore, the only time when there is a hard requirement to remove a
dependency without alternative are self cycles which currently involve only
about 30 source packages. For all other source packages there are always
alternatives. So you will mostly not get into a situation where you absolutely
"need to break a build-dep loop" as you describe it above (aside from these 30
source packages).
> > 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.
Why? The build dependencies which are not metapackages are not listed as false
positives because they get weeded out in the first phase.
> 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.
You are right. I'll see what I can do.
Thanks a lot for your input!
cheers, josch
Reply to: