Hi, Quoting Bill Allombert (2021-11-17 14:40:57) > On Wed, Nov 17, 2021 at 01:31:33PM +0100, Johannes Schauer Marin Rodrigues wrote: > > Quoting Bill Allombert (2021-11-17 13:06:09) > > > > 1. "they are not normally used by the Debian autobuilders" should instead > > > > be "they are never used by the Debian autobuilders" or it should state > > > > when they are used and when they are not > > > > > > If the base system on top of which the build-dependencies are to be > > > installed already include one of the alternative then it is used in > > > preference to the others. > > > > But this is not what happens on the buildds. Sbuild munges all alternatives in > > B-D, B-D-I and B-D-A irrespective of the packages that are already installed > > and only passes the resulting meta-package to apt which cannot know anymore of > > the original alternatives. > > ... but it does not remove the already installed alternatives, > so the Alternative is not used even though the alternative package is > installed ? Suppose a source package has: Build-Depends: A | B Then sbuild will create a dummy-package with: Depends: A So even if B were already installed in the chroot, apt would still install A to satisfy the dependency of the dummy package. Whether or not the build process uses A or B is of course up to the build scripts of the source package itself. > This footnote might not be the best place to document the precise behaviour > of autobuilders (which currently is outside the scope of policy). On the > other hand, having a fully specified build process could reduce build > variability and make builds more reproducible. Do you have suggestions for a better place to document this? I'm filing this because I suggested that apt would gain support for this behaviour of sbuild/buildd so that "apt-get build-dep" would do something that is closer to what happens on the official buildds. And for good reason apt developers asked if this behaviour was documented somewhere. Nevertheless, even if the full explanation was written down somewhere else, the policy text should be updated to correctly document what is happening instead of being imprecise and/or wrong about reality. Or the footnote should be removed completely to avoid the three problems with it I pointed out in my initial report. Thanks! cheers, josch
Attachment:
signature.asc
Description: signature