Re: alternative dependency ordering - with respect of packages in main
On Tue, Sep 20, 2011 at 07:41:11PM +0200, Luk Claes wrote:
> On 09/20/2011 01:12 PM, Gerfried Fuchs wrote:
> > 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:
> That being said, it might be that having a predictable set of build
> dependencies on the buildds is not wanted anymore?
I'm fairly certain that we do want predictability and consistency.
> > 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.
Just to comment on the build dependencies: first-only alternatives
are only implemented for Build-Depends and Build-Depends-Indep
(for all resolvers). They get stripped when computing the set of
packages to install.
Alternatives in regular package Depends are delegated to
apt-get/aptitude, and what is installed will depend upon what is
available and installable. For packages being build for main, the
contrib and non-free archives should not be available, so such
alternatives should not be considered.
.''`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/
`- GPG Public Key: 0x25BFB848 Please GPG sign your mail.