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 -- 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/20140708042249.14505.27900@hoothoot
