On Tue, Jul 08, 2014 at 06:22:49AM +0200, Johannes Schauer wrote: > 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. But it absolutely does have this effect if we add bootstrap-specific metadata unnecessarily, because: - it introduces a syntax incompatibility with older versions of the package tools - it makes the packaging more complex to understand The latter point is as likely to cause problems for the bootstrappers themselves as it is for the maintainers, since the more maintainers who have to get this metadata right and keep it up to date, the more it's going to bitrot. > 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. I'm happy that tools like botch exist and think botch has been a useful accelerator for bootstrappability of Debian. However, my own goal is to see that future port bootstraps can be done using the standard buildd infrastructure (for each of Debian and Ubuntu), which doesn't currently make use of such techniques - rather, they work by building everything which is buildable. If you plan to wire up botch to wanna-build for archive-friendly bootstrappability, that would be great to see! But until that's happened, I stand by my claim that stage1 data not needed for breaking build-dep loops is counterproductive for bootstrapping ports. > > > 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. Because "package misbuilds when a metapackage it build-depends on is broken" is an arbitrary subset of "package misbuilds when build-depends are broken", and it does not benefit Debian to have maintainers focusing on such an arbitrary subset. Cheers, -- 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