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

Bug#587279: debian-policy: section 2.2.1 needs some tweaking



On Tue, Jun 29, 2010 at 10:31:57AM -0700, Russ Allbery wrote:
> Raphael Geissert <geissert@debian.org> writes:
> 
> > I see a couple of issues with the current section 2.2.1 "The main
> > archive area:"
> 
> > a) It does not list neither Pre-Depends nor Build-depends-indep.
> > b) It does not take into consideration ORed dependencies.
> 
> > Point a) can be fixed by listing those two fields and maybe even toning
> > down the statement in parenthesis (e.g. s/thus/e.g./.)
> 
> I think we should keep the parenthetical strong since it's currently the
> only place that we say that Recommends from main to non-free is not
> allowed, which is otherwise not obvious.
> 
> > The problematic mentioned in b) is that with the current wording one
> > could say that the following is not allowed for a package in main:
> 
> > Depends: package-in-main | package-in-non-free
> 
> > Real example:
> > Depends: unrar-free | rar
> 
> > (unrar-free is in mai, rar is in non-free.)
> 
> I'm committing the following change for the next release which differs
> slightly from Raphael's in that it uses better markup for the field names
> (fixing an existing minor inconsistency) and doesn't specify the first
> alternative.  Packages listing the non-free alternative first are probably
> buggy in other ways, and if someone wants to propose wording elsewhere to
> deal with that I'd probably second it, but they don't fail this particular
> section because they don't require a non-free package to work.
> 
> I think this is informative, not normative, since it just clarifies the
> existing requirement and doesn't change the basic requirements, so I'm
> going ahead and committing this, but if anyone thinks that's too
> aggressive, do speak up.

I disagree that adding an explicit allowance for alternative is not a normative change. 

The old wording (the package must not declare a "Depends", "Recommends", or
"Build-Depends" relationship on a non-main package) is quite clear that alternative
are not allowed.

Part of the "non-free is not part of Debian" deal was that Debian (main) would not
"advertize" non-free software. Allowing non-free software to be listed in the
Depends/Recommends field breaks that. 

In the example:
Package: foo
Depends: unrar-free | rar

rar could Provides: unrar-free
and foo would only need to Depends: unrar-free
(Or better: unrar-free would be renamed to unrar, rar to rar-nonfree and rar-nonfree would
provide unrar)

Cheers,
-- 
Bill. <ballombe@debian.org>

Imagine a large red swirl here. 

Attachment: signature.asc
Description: Digital signature


Reply to: