Hi there, On Sat, Aug 13, 2011 at 01:28:36PM +0200, Andreas Barth wrote: > Introducing Build-Recommends / Build-Core-Depends > We should be able to specify in the package saying "only these > build-dependencies are needed to get a functionally working package". > For such an build, the packages which are not needed for building > working core packages are annoted in an additional header (e.g. > Build-Recommends), but are still specified in Build-Depends to not > break the old tools. > Optionally, we could introduce Build-Core-Depends which only has > the minimum set of build-dependencies the package needs. Technically, > that's not that large a difference but just a different way of writing > it down. Build-Recommends is a bad name for this for two reasons: 1) Since Build-Depends would still contain the full set of build-dependencies for compatibility with existing tools, the buildds would have to calculate the *difference* between Build-Recommends and Build-Depends to determine which packages need to be installed for a bootstrapping build. It's better to just declare outright which dependencies should be used for the bootstrap (which is likely to be a small and rarely changing set, easier for the maintainer to keep track of anyway). 2) The name implies a *choice* about whether to use these packages when building - leading inevitably to the sorts of discussions we've already seen in this thread about extending this into an equivalent of Gentoo USE flags. We do *not* want that kind of unmaintanable stew; we should use this interface solely for bootstrapping, and the field names should suggest this. So Build-Core-Depends would certainly be a better approach, but I wonder why this isn't being called Build-Depends-Stage1 or similar? I know that has been discussed in the recent past. > Also, the binary packages in the debian/control template could have > Build-Depends specified which means that they should only be built if > those packages are actually installed (so we could do an automated > graph analyis, and also dh and cdbs could just drop them, so that > debian/rules doesn't need to reflect the dependencies); however, any > package in an binary packages build-depends needs to be part of the > source package build-depends-line so that just downloading all > build-depends does the right thing (as of now). Packages with no > additional Build-Depends specified can be built with the minimum set > installed. Per-binary-package build-depends would be very inelegant. They're only useful if the parts requiring additional bootstrapping are split into separate binary packages, and as we know that won't always be the case, this adds very little to the design. I don't think that debian/rules should be silently discarding binary packages based on what build-dependencies are installed anyway - that would certainly break the behavior of dpkg-buildpackage -d, for one thing. Can you elaborate on how you see this helping with automated graph analysis? If the goal is to get the entire archive bootstrapped, which I assume it is, then the mere existence of a Build-Depends-Stage1 field is sufficient to tell us everything we need to know about bootstrapping order. (If it isn't, then that implies we actually need a Build-Depends-Stage2 as well. I understand no one has found such a case of nested build-dependency loops yet, so we should probably just ignore this possibility; but if you think this is a real risk, all the more reason to use "Stage1" notation which is extensible in the obvious way.) > Building with core Dependencies only > If doing an build of the core functionality only, norecommends is > added to the environment DEB_BUILD_OPTIONS. This is the signal for > dpkg-buildpackage etc to only check for the minimal set of packages, > and for the debian/rules to accept if some functionality is missing > (i.e. might require changes to usage of ./configure). s/norecommends/stage1/ :) > (Buildds should do it in a way that they first check if however all > recommends are available, and only failing that setting the header - > makes it more likely we get full packages early; but that's an > implementation sidenote). Full ack... > Resulting packages > All binary packages built need to be functionally working, and follow > the standard for packages on ftp-master. This means they could e.g. > miss documentation (as long as they are not RC-buggy, i.e. they need > to have changelog and copyright), and that it might be that not all > binary packages are built (e.g. via the Build-Dependency-mechanimsn in > debian/control above). Often cutting off documentation and graphical > packages is enough for a minimal version. Why is it important that these packages follow the standards for packages on ftp-master? Do you intend to have such packages published to the main archive? Wouldn't it be better to stow bootstrap packages in a separate archive that's only used by the buildds? (In which case, do we really care about trying to set explicit policy for what's in them...?) > To mark such packages and to be able to decide when to re-schedule the > build, all binary-packages get the additional header > Build-Depends: minmal package_version .... > injected, so that one could see later on that this was a partial build > and reschedule a new build when newly upcoming packages allow more > binary packages to be built, or all build-dependencies are available > and we could do a clean full build. Why should this header be anything more than a flag? E.g., 'Stage-1: yes'? I think this proposal overloads the meaning of 'Build-Depends', and I don't see what value it adds over a simple flag. > It would be nice if wanna-build could cope with such packages in a > more sensible way, but that's already not so necessary anymore. I don't see why that's not necessary. Is this because you intend to use some other internal tool to walk the tree and inject binNMU requests, or something? 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