Re: alternative dependency ordering - with respect of packages in main
On 09/20/2011 01:12 PM, Gerfried Fuchs wrote:
> Hi!
Hi
> Policy is clear on packages in main aren't allowed to depend on
> packages outside of main. Now in a fair amount of cases this has been
> worked around by having the package outside of main as alternative
> dependency and a package in main offer basic functionality for the
> package to still be able to work.
>
> I know that the buildd system likes to pull in the first package in
> such an alternative dependency chain. And now I start to wonder:
The reason the buildd system only looks at the first alternative is to
have a predictable set of build dependencies. The same is true for
having the first alternative being in main as otherwise it might depend
on the config of the buildd whether it will install the dependency in
main or another one.
That being said, it might be that having a predictable set of build
dependencies on the buildds is not wanted anymore?
> Is it allowed for a package in main to have a package _outside_ of main
> as first component of an alternative dependency? The package in
> question is extremely unlikely to ever be used as Build-Depends, so this
> is of a more general question.
Strictly speaking having an alternative dependency outside main is
already bending the rules very far. The only reason I see why an
alternative outside main is allowed, is that one could easily do
something similar when using Provides.
> tl;dr - what do you think, is a "Depends: foo-contrib | foo" acceptable
> for packages in main or should it be "Depends: foo | foo-contrib"
> instead?
Personally I think we should stay with a predictable set of build
dependencies on the buildds (only have them look at the first
alternative) and we should stay with having a package in main as the
first alternative of a build dependency of a package in main.
Cheers
Luk
Reply to: