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

[Johannes Schauer]

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.

> 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.

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.

But you bring up a good point! Even when apt 1.1 hits old-old-stable, we could
still not switch to a "apt-get build-dep foo.dsc" based system if we want to
retain sbuild's ability to mangle build depends:

 - to remove alternatives

 - to inject additional dependencies via --add-depends and friends

I'll update my commit message with that note.

Thanks!

cheers, josch
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: signature
URL: <http://lists.alioth.debian.org/pipermail/buildd-tools-devel/attachments/20160106/ad187efb/attachment.sig>