Re: re buildd's resolver and package's build deps
Roger Leigh <email@example.com> writes:
> On Mon, Feb 28, 2011 at 03:36:47PM +0100, Wouter Verhelst wrote:
>> On Tue, Feb 22, 2011 at 05:08:18PM +0000, Roger Leigh wrote:
>> > On Mon, Feb 21, 2011 at 07:42:32PM -0600, Raphael Geissert wrote:
>> > > I disagree here.
>> > > Alternatives in build-* relationships *are* mentioned by policy. In fact,
>> > > there's even an example in section 7.1.
>> > This is correct. I was thinking about drafting a patch for Policy
>> > about this. Current Policy defines the allowed syntax for
>> > Build-Depends. It does not however, make any mention of existing
>> > conventions and best practices, which I feel should be addressed.
>> > The current "internal" build dependency resolver does not make
>> > any use of the alternative dependencies. It always picks the first.
>> It was my understanding that there are some corner cases in which it
>> would select the second:
>> - where one build-dependency (indirectly) depends on a secondly-listed
>> alternative, it could install the second.
>> - sbuild will not worry about installing the first alternative if the
>> second has already been installed.
>> but I might be mistaken about one or both of the above.
> I'm not totally sure either, to be honest. The internal resolver code
> is horrible. It looks like it still has relics of manual source-deps
> entangled in there as well (but I don't dare to touch it since it will
> probably break horribly if I delete it). The alternatives processing
> is in Sbuild::InternalResolver::parse_one_srcdep and
> filter_dependencies, and it looks like it could well be OK with second
> alternatives if installed.
You are not mistaken. At least in the past the resolver would first
remove all packages from Build-Depends that are already installed. Only
those part of Build-Depends that are unfullfilled are installed using
the first alternative after arch reduction.