[buildd-tools-devel] Bug#809730: [Multiarch-devel] multiarch cross build dependency resolution

[Roger Leigh]

On 06/01/2016 10:19, Johannes Schauer wrote:
> Hi,
>
> Quoting Roger Leigh (2016-01-06 10:51:53)
>> On 06/01/2016 09:40, Johannes Schauer wrote:
>>> It could be argued that sbuild should use 'apt-get build-dep' for all
>>> its operation including native compilation. This would mean that quite
>>> some logic could be removed from sbuild.
>>
>> Historically this was broken for sbuild use.  Maybe that's changed now?
>
> probably. It works fine for cross building.

Great!

>> The major difference in behaviour is the handling of alternative build
>> deps.  Unless something has changed, apt-get build-dep didn't provide
>> the deterministic behaviour of sbuild's resolver.
>
> That could still be done even with using "apt-get build-dep" just by
> controlling what ends up in the generated Sources file just as it is currently
> done for the dummy binary package.

Definitely.  If it's possible to do this, then it sounds like a nice way 
to remove unnecessary functionality from sbuild and use apt to do the 
work.  So long as the dummy repo with the sources file takes priority 
then it sounds like a good solution.

> A funny side note here is, that the resolver behaviour never fully
> deterministic (for some meaning of the word deterministic). Sbuild itself will
> remove direct Build-Depends alternatives but this will not influence:
>
>   - indirect alternatives like: src:A depends B depends C|D
>
>   - virtual packages: src:A depends B which is provided by C and D
>
> Nevertheless, modifying direct dependencies is still a useful hack in some
> situations.

Yes.  It was never perfect; to get that you'd have to have the apt 
resolver itself be able to handle the indirect dependencies as well. 
OTOH, they are regular dependencies and not source dependencies, so you 
could argue that they don't matter perhaps.  If you're always installing 
from a clean chroot, hopefully that is always deterministic!


Regards,
Roger