On Sat, Feb 26, 2011 at 10:25:48PM +0000, Roger Leigh wrote: > On Sat, Feb 26, 2011 at 10:39:51AM -0800, Steve Langasek wrote: > > On Wed, Feb 23, 2011 at 05:52:27PM +0100, Cyril Brulebois wrote:
> > > Tiny question: you say it eases backports. But then backports get > > > autobuilt on debian buildds, so will likely use the same set of > > > packages as say unstable, if build-depends aren't changed specifically > > > for the backports. So I'm not exactly sure it actually eases anything. > > The one aspect of the current buildd behavior not addressed here is that the > > autobuilders will only *consider* the first alternative build-dep for > > *installation*; but if at the end of b-d installation the full build-dep > > relationship is satisfied because a different package was pulled in (or > > previously installed) that satisfies one of the other alternatives, the > > build dependencies of the package as a whole are considered satisfied. > > This was touched on briefly in <20110223115755.gm31...@codelibre.net> on > > debian-devel. > Yes, this is a very good point. None of the resolvers do a good job at > enforcing things post-installation (historically). And > dpkg-buildpackage will also consider all alternatives when checking > they are satisfied as well. > I think that one recent change does enforce this, however. Previously, > the internal resolver would just pick the first alternative, and then > do the necessary package installation/removal to satisfy things, but > would not subsequently enforce things. The new dependency package > support in the apt and aptitude resolvers /will/ enforce the first-only > alternatives installation. This is because the arch-reduced, first-only > alternatives are in the Depends: of the dependency package. The other > alternatives are not present in the Depends: at all (unless you enable > it). Thus, the other alternatives aren't considered, and because the > dependency package is installed for the duration of the build, we are > enforcing installation of the first-only alternatives under all > circumstances, even when the build-deps could be satisfied through > other alternatives. > Note this isn't yet in use on the buildds, but it is present in the > unstable sbuild. Sorry, I wasn't meaning to suggest that the existing implementation "doesn't do a good job at enforcing". Rather, I wanted to raise the question of whether this is the behavior we want. There are cases that the current behavior supports that I don't see any other way to support in an automated fashion (specifically in a backports context); but we may decide that the semantics are sufficiently opaque here that we'd rather drop support for this anyway. -- 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/ slanga...@ubuntu.com vor...@debian.org
signature.asc
Description: Digital signature
