On Tue, Feb 22, 2011 at 10:21:24PM +0100, Bill Allombert wrote:
> On Tue, Feb 22, 2011 at 06:49:21PM +0000, Ian Jackson wrote:
> > Roger Leigh writes ("Re: re buildd's resolver and package's build deps"):
> > > I agree that these do serve a useful purpose for these uses, and that
> > > ease of reuse backporting and other types of porting are important.
> > > However, there is no way to know which of those alternatives applies
> > > to which suite. All of them are potentially going to be used for a
> > > build in unstable, and it's this uncertainty which could potentially
> > > lead to inconsistent builds.
> >
> > Well then some mechanism needs to exist to make it predictable. The
> > current arrangement, where buildds always use the first alternative,
> > seems like a pretty simple one. Is it not adequate ?
>
> I think it is. What is missing is a flag for dpkg-checkbuilddeps (and
> dpkg-buildpackage) to enforce that behaviour, so that users can rebuild
> packages in the predictable way without using a buildd.
This would be a very useful addition. On its own, it won't be
sufficient to give a clean build though; that would still require a
minimal chroot environment to avoid autodetection and enabling of
additional things (depending upon the package).
From discussion on IRC earlier this evening, it looks like the most
pragmatic approach will be to get the apt and aptitude sbuild
resolvers to strip the alternatives (after arch reduction), which
will make them behave pretty much exactly like the old internal
resolver, but without its bugs. This will leave maintainers free to
use alternative dependencies, but like now they will be ignored.
What we can do though, is make the use of alternatives configurable
in sbuild, so you will be able to make use of them when building for
other suites e.g. backports. This will disable the stripping.
On the other hand, this does mean that building for unstable will
mean no alternatives will be allowed other than arch-specific ones.
This should probably be documented in Policy, if the consensus is
that this is the best way to go.
Regards,
Roger
--
.''`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/
`- GPG Public Key: 0x25BFB848 Please GPG sign your mail.
Attachment:
signature.asc
Description: Digital signature