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

Bug#681419: marked as done (Alternative dependencies on non-free packages in main)

Your message dated Fri, 31 Oct 2014 14:55:02 -0700
with message-id <20141031215502.GA26165@teltox.donarmstrong.com>
and subject line Re: Alternative dependencies on non-free packages in main: Call for Votes
has caused the Debian Bug report #681419,
regarding Alternative dependencies on non-free packages in main
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
681419: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=681419
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: tech-ctte
Severity: normal

As a Debian Policy delegate, I'm delegating to the Technical Committee
the resolution of bugs #587279 and #616462.

The current Policy wording is:

    In addition, the packages in main

     * must not require or recommend a package outside of main
       for compilation or execution (thus, the package must not declare
       a "Pre-Depends", "Depends", "Recommends", "Build-Depends", or
       "Build-Depends-Indep" relationship on a non-main package),

The question at issue in these bugs is whether it is permissible for
a package in main to declare a non-default alternative dependency on
a package in non-free.  In other words, may a package in main have a
dependency of:

    Depends: foo | foo-nonfree

(I believe that the question of whether "foo-nonfree | foo" should be
allowed is not at issue and that the consensus is that it's not
permitted.  However, the Technical Committee can certainly open that
discussion if desired.)

Please see the bugs cited above for the complete earlier discussion.
(Note that the end of #587279 has some off-topic discussion of the
exact meaning of "require or recommend a package" that's not at issue
in this bug.  I don't think the requested bug about that issue was
ever filed, so I'm inclined to not consider it an issue currently.)

--- End Message ---
--- Begin Message --- 
With 

A,B,FD: (6) Steve, Russ, Bdale, Keith, Don, Andreas
B,A,FD: (2) Ian, Colin

A is the CTTE decision:

Whereas

1. The Debian Policy Manual states (�2.2.1) that packages in main
   "must not require or recommend a package outside of main for
   compilation or execution".  Both "Depends: package-in-non-free" and
   "Recommends: package-in-non-free" clearly violate this requirement.
   The Technical Committee has been asked to determine whether a
   dependency of the form "package-in-main | package-in-non-free"
   complies with this policy requirement, or whether virtual packages
   must instead be used to avoid mentioning the non-free alternative.

2. Both options have the following effects in common, meeting the
   standard that main should be functional and useful while being
   self-contained:

  (a) Package managers configured to consider only main will install
      package-in-main.

  (b) Package managers configured to consider both main and non-free
      will prefer to install package-in-main, but may install
      package-in-non-free instead if so instructed, or if
      package-in-main is uninstallable.

  (c) If package-in-non-free is already installed, package managers
      will proceed without installing package-in-main.

3. The significant difference between these two options is that the
   former makes the non-free alternative visible to everyone who
   examines the dependency relationship, while the latter does not.

4. Merely mentioning that a non-free alternative exists does not
   constitute a recommendation of that alternative.  For example, many
   free software packages state quite reasonably that they can be
   compiled and executed on non-free platforms.

5. Furthermore, virtual packages are often a clumsy way to express
   these kinds of alternatives.  If a package happens to require any
   of several implementations of a facility that have a certain
   option, then it can either depend on suitable alternatives
   directly, or its maintainer can first attempt to have fine-grained
   virtual packages added to each of the packages they wish to permit.
   In some cases this may be appropriate, but it can easily turn into
   quite a heavyweight approach.

Therefore:

6. The Technical Committee resolves that alternative dependencies of
   the form "Depends: package-in-main | package-in-non-free" are
   permissible in main, and do not constitute a violation of the
   policy clause cited in point 1.

7. We nevertheless recommend that packages in main consider carefully
   whether this might cause the inadvertent installation of non-free
   packages due to conflicts, especially those with usage
   restrictions.

-- 
Don Armstrong                      http://www.donarmstrong.com

If I had a letter, sealed it in a locked vault and hid the vault
somewhere in New York. Then told you to read the letter, thats not
security, thats obscurity. If I made a letter, sealed it in a vault,
gave you the blueprints of the vault, the combinations of 1000 other
vaults, access to the best lock smiths in the world, then told you to
read the letter, and you still can't, thats security.
 -- Bruce Schneier

--- End Message ---
Reply to: