[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: re buildd's resolver and package's build deps

Roger Leigh <rleigh@codelibre.net> 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.


Reply to: