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

[Charles Plessy]

Le Wed, Mar 14, 2012 at 01:21:51AM -0400, Michael Gilbert a écrit :
> 
> Think about it this way.  Say the remote firmware files that getweb
> currently fetches were instead put in a package called
> foo2zjs-nonfree.  That package would (of course) have to be located in
> non-free, and any packages depending on that would need to be located
> in at least contrib, right?

Dear Michael,

having a foo2zjs-nonfree package would allow other packages that specifically
need the drivers downloaded by getweb to depend on it and make sure that if
they are installed, the drivers are present.  This is a typical contrib
or non-free situation.

In contrary, if the foo2zjs package allows to download non-free drivers
manually, and does not do it automatically at installation, and if no package
depending on foo2zjs need that getweb has been executed, then the requirement
that no Debian package depends on anything outside the main Debian archive is
satisfied.

I think that this helps to draw the line: to consider that what matters is not
whether a program can download non-free software or not, but whether the result
of the installation of a package is that non-free software has been installed.

Have a nice day,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

[Russ Allbery]

Michael Gilbert  writes:

> The important consequence of a potential policy change/clarification
> here, is that pushing these oddballs out of main solves all of the
> problems: security authenticity/integrity, non-freeness, brokenness,
> trustworthiness, etc.  They're all good qualities that would be achieved
> via modest policy clarification, and would clearly (in my opinion) make
> main better.  That's why I still think this concept is worth pursuing
> and contemplating a bit more, even if it does have the downside that it
> will cause a bit of pain in a few packages.

Oh, okay, well, that's a different goal.  That is *definitely* not a
"modest policy clarification"; that's a substantial change to Debian
archive policy, probably rising to the GR level.

If you want to pursue that, please open a separate Policy bug at the very
least, and I suspect you will need to start with a GR; I think it will
require a GR to reject from main packages that install unsigned code.

-- 
Russ Allbery (r...@debian.org)   



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

[Michael Gilbert]

On Wed, Mar 14, 2012 at 5:18 PM, Russ Allbery wrote:
> Michael Gilbert writes:
>> On Wed, Mar 14, 2012 at 1:43 AM, Russ Allbery wrote:
>
>>> I think you're in the "rough" of "rough consensus."
>
>> It takes some moxie to put a dent into the status quo.  If that's rough,
>> so be it.  I try my best to be kind and constructive though.  Really
>> I've tried to avoid anything potentially confrontational for a long long
>> time now.
>
> Ack, sorry.  That's a term from the IETF that I think is too easy to
> misinterpret out of context.  I didn't mean to say that you were being
> rough or confrontational to anyone.
>
> The intent of the phrase is to capture the fact that consensus-based
> decision-making doesn't mean that everyone agrees.  Consensus isn't
> unanimity, particularly "rough consensus," which is the metric that the
> IETF uses formally and that Debian uses in practice.  When someone
> disagrees with the consensus but still seems clearly outnumbered and
> doesn't succeed in persauding others that there is not consensus, they're
> said to be in the "rough" of the "rough consensus."
>
> Think the "rough" of a golf course, not "rough" as in confrontational or
> aggressive.

OK, thanks for the explainaton.

>> Well, there was the recent -devel thread on essentially the same
>> topic: something like "holes in our software fortress".
>
> Which was about yet a third separate topic, namely cryptographic
> verification of executable code retrieved from the network, and is
> unrelated to whether or not that code is non-free.

Well like I've been trying to say, the issue is quite multi-faceted.
I went to great lengths to break it down from all perspectives
including crypto/security in one of my messages to the foo2zjs bug:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=449497#212

The important consequence of a potential policy change/clarification
here, is  that pushing these oddballs out of main solves all of the
problems: security authenticity/integrity, non-freeness, brokenness,
trustworthiness, etc.  They're all good qualities that would be
achieved via modest policy clarification, and would clearly (in my
opinion) make main better.  That's why I still think this concept is
worth pursuing and contemplating a bit more, even if it does have  the
downside that it will cause a bit of pain in a few packages.

Best wishes,
Mike



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

[Russ Allbery]

Michael Gilbert  writes:
> On Wed, Mar 14, 2012 at 1:43 AM, Russ Allbery wrote:

>> I think you're in the "rough" of "rough consensus."

> It takes some moxie to put a dent into the status quo.  If that's rough,
> so be it.  I try my best to be kind and constructive though.  Really
> I've tried to avoid anything potentially confrontational for a long long
> time now.

Ack, sorry.  That's a term from the IETF that I think is too easy to
misinterpret out of context.  I didn't mean to say that you were being
rough or confrontational to anyone.

The intent of the phrase is to capture the fact that consensus-based
decision-making doesn't mean that everyone agrees.  Consensus isn't
unanimity, particularly "rough consensus," which is the metric that the
IETF uses formally and that Debian uses in practice.  When someone
disagrees with the consensus but still seems clearly outnumbered and
doesn't succeed in persauding others that there is not consensus, they're
said to be in the "rough" of the "rough consensus."

Think the "rough" of a golf course, not "rough" as in confrontational or
aggressive.

> Well, there was the recent -devel thread on essentially the same
> topic: something like "holes in our software fortress".

Which was about yet a third separate topic, namely cryptographic
verification of executable code retrieved from the network, and is
unrelated to whether or not that code is non-free.

> I think Ben's rewording would be good.

I'm also okay with Ben's rewording, and am inclined to apply it for the
next Policy release.  If anyone disagrees, speak up.

-- 
Russ Allbery (r...@debian.org)   



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

[Michael Gilbert]

On Wed, Mar 14, 2012 at 1:43 AM, Russ Allbery wrote:
> Michael Gilbert writes:
>
>> Opinions are malleable (wrong and right are all a matter of
>> perspective).  This is something sufficiently nuanced that I think its
>> worth sufficient pondering to really get it right.  If you haven't spent
>> much time pondering those nuances, it's easy to assume perspective of
>> the status quo.
>
> But I have spent much time pondering these nuances and have decided that
> while your opinion makes sense and comes from a set of reasonable
> assumptions, I don't agree with it.
>
> When I said I wasn't interested in reopening this discussion, I really
> meant it.

A little bit of discussion and critical thought is healthy.  In fact
alternative viewpoints are very healthy for drawing informed opinions.

I understand you're probably very busy with other things and this is a
bit of a distraction.  I apologize for consuming some of your time.

I'm a logical person, so if you can poke a hole in the logic of the
thought experiment above, or even provide a reasoned argument for your
viewpoint, you could probably end my concerns rather quickly.  This
"move along, nothing to see here" argument is not constructive.

> My perception is that the project made a decision on this case
> (one that I happen to think is right) and there's no great clamour to
> reopen the topic.  You don't agree with that decision, which is perfectly
> reasonable.

The project as a whole rarely makes decisions (except in cases of
GRs).  The current status quo is basically the due to the path of
least resistance.  Even though the problem remains, no one is doing
anything due to inertia, even though very few oddball packages would
even be affected.

> I think you're in the "rough" of "rough consensus."

It takes some moxie to put a dent into the status quo.  If that's
rough, so be it.  I try my best to be kind and constructive though.
Really I've tried to avoid anything potentially confrontational for a
long long time now.

> If such a clamour arises, then of course that's a different situation.

Well, there was the recent -devel thread on essentially the same
topic: something like "holes in our software fortress".  It's not
going to go away, why not spend a little time to get it right and get
it over with?

> Anyway, I think this is irrelevant to the wording debate, since the core
> of that argument is over what it means to "depend on or recommend" or to
> "require" other software, and that's not something we're going to resolve
> by tweaking the wording.

So,  dfsg licensing handles certain odd/esoteric cases by using
thought experiments like the tentacles of evil.  My thought experiment
certainly isn't as interestingly titled, but it is something that
could be used to decide these grey-area dependency situations.  Sorry
for choosing getweb so much, but that's the best reference point I
have.  It's for example purposes.  Not because I really even care
about that package.

>> Right, I wasn't trying to say that.  My point was more that the lead-in
>> paragraph as it is now is only descriptive, but given the wording
>> doesn't actually lay out any of particular requirements (more so it lays
>> out the ideals of main).  The requirements themselves actually start
>> with, "Every package in main must comply" then continues with "In
>> addition to" and then the bullets.
>
> Yes, this is the point where we don't agree.  You feel that because there
> isn't a "must" in the first paragraph, it's not a requirement.  I think
> the first paragraph is clearly a requirement, whether it includes the word
> "must" or not.  It's typical in standards that statements of fact like
> "nothing in main requires software outside of main to function" constitute
> a requirement placed on software going in main, regardless of whether it
> uses a specific standards word.  In other words, you aren't allowed to do
> something that makes factual statements in the policy document false.

I think Ben's rewording would be good.

> (This comes up frequently in descriptions of syntax.  It's usually both
> tedious and pointless to add "must" words everywhere to say that people
> aren't allowed to violate the syntax.)
>
> If it would result in less argument, I can support rephrasing the first
> paragraph to include the magic word "must" around "does not require
> software outside of main to function."
>
>> It's not unclear per se, but there remain ambiguities in terminology
>> making it possible to interpret it in various slightly incompatible
>> fashions: the choice of the term "package" vs. "software" makes it
>> appear ok to have non-main "software" depends/recommends but not ok to
>> have "package" depends/recommends.
>
> The reason why I'm somewhat unenthused about tweaking the wording here is
> that there are *always* going to be ways to interpret human language other
> ways, particularly in an area like this that's rife with acknowledged grey
> areas (like emulators that are mostly use

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

[Ben Finney]

Russ Allbery  writes:

> Here is the complete text [of the current Policy §2.2.1]:
>
> The main archive area comprises the Debian distribution. Only the
> packages in this area are considered part of the distribution.
> None of the packages in the main archive area require software
> outside of that area to function. Anyone may use, share, modify
> and redistribute the packages in this archive area freely […]

I think the meaning is clear, and it matches Russ's interpretation.


Russ Allbery  writes:

> If it would result in less argument, I can support rephrasing the
> first paragraph to include the magic word "must" around "does not
> require software outside of main to function."

Regardless of whether such a patch is necessary, I present the following
for your consideration:

--- a/policy.sgml
+++ b/policy.sgml
@@ -475,15 +475,16 @@
  
The main archive area comprises the Debian
distribution.  Only the packages in this area are considered
-   part of the distribution.  None of the packages in
-   the main archive area require software outside of
-   that area to function.  Anyone may use, share, modify and
-   redistribute the packages in this archive area
-   freely
+   part of the distribution.
+ 
+
+ Every package in main must be free
  See http://www.debian.org/intro/free";
   name="What Does Free Mean?"> for
  more about what we mean by free software.
-   .
+for anyone to use, share, modify, and redistribute,
+   and must function without requiring works outside of
+   the main area.
  

  


I believe this does not change the meaning of that section. It separates
the wording into an informative statement of fact, followed by the
normative language.

-- 
 \ “We now have access to so much information that we can find |
  `\  support for any prejudice or opinion.” —David Suzuki, 2008-06-27 |
_o__)  |
Ben Finney



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

[Russ Allbery]

Michael Gilbert  writes:

> Opinions are malleable (wrong and right are all a matter of
> perspective).  This is something sufficiently nuanced that I think its
> worth sufficient pondering to really get it right.  If you haven't spent
> much time pondering those nuances, it's easy to assume perspective of
> the status quo.

But I have spent much time pondering these nuances and have decided that
while your opinion makes sense and comes from a set of reasonable
assumptions, I don't agree with it.

When I said I wasn't interested in reopening this discussion, I really
meant it.  My perception is that the project made a decision on this case
(one that I happen to think is right) and there's no great clamour to
reopen the topic.  You don't agree with that decision, which is perfectly
reasonable.  I think you're in the "rough" of "rough consensus."

If such a clamour arises, then of course that's a different situation.

Anyway, I think this is irrelevant to the wording debate, since the core
of that argument is over what it means to "depend on or recommend" or to
"require" other software, and that's not something we're going to resolve
by tweaking the wording.

> Right, I wasn't trying to say that.  My point was more that the lead-in
> paragraph as it is now is only descriptive, but given the wording
> doesn't actually lay out any of particular requirements (more so it lays
> out the ideals of main).  The requirements themselves actually start
> with, "Every package in main must comply" then continues with "In
> addition to" and then the bullets.

Yes, this is the point where we don't agree.  You feel that because there
isn't a "must" in the first paragraph, it's not a requirement.  I think
the first paragraph is clearly a requirement, whether it includes the word
"must" or not.  It's typical in standards that statements of fact like
"nothing in main requires software outside of main to function" constitute
a requirement placed on software going in main, regardless of whether it
uses a specific standards word.  In other words, you aren't allowed to do
something that makes factual statements in the policy document false.

(This comes up frequently in descriptions of syntax.  It's usually both
tedious and pointless to add "must" words everywhere to say that people
aren't allowed to violate the syntax.)

If it would result in less argument, I can support rephrasing the first
paragraph to include the magic word "must" around "does not require
software outside of main to function."

> It's not unclear per se, but there remain ambiguities in terminology
> making it possible to interpret it in various slightly incompatible
> fashions: the choice of the term "package" vs. "software" makes it
> appear ok to have non-main "software" depends/recommends but not ok to
> have "package" depends/recommends.

The reason why I'm somewhat unenthused about tweaking the wording here is
that there are *always* going to be ways to interpret human language other
ways, particularly in an area like this that's rife with acknowledged grey
areas (like emulators that are mostly used to play non-free ROMs but can
also play the -- often nearly nonexistent -- free ROMs).  In other words,
I'm skeptical whether changing the language here is going to result in
fewer discussions like this, and whether it's going to actually resolve
confusion, as opposed to being a debating stick.

-- 
Russ Allbery (r...@debian.org)   



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

[Michael Gilbert]

On Tue, Mar 13, 2012 at 11:27 PM, Russ Allbery wrote:
> Michael Gilbert writes:
>
>> I understand this section very well, and even with that lead-in wording,
>> I contend that sufficient ambiguity remains that additional clarity is
>> needed.  Otherwise, it wouldn't have been so difficult to deal with bug
>> #449497, which essentially turned into a wontfix.
>
> No, that bug is a different argument (the one about what it means to
> "require software").

It's more nuanced than that.

Think about it this way.  Say the remote firmware files that getweb
currently fetches were instead put in a package called
foo2zjs-nonfree.  That package would (of course) have to be located in
non-free, and any packages depending on that would need to be located
in at least contrib, right?

Now the majority of foo2zjs doesn't depend on those files, but it can
make use of them if/when they're available.  Now that there is no need
to fetch external files, getweb is dropped from the package.  Based on
those two facts, its obvious that this new version of the package
appropriately belongs in main.

For the sake of argument, lets assume that the upstream build system
doesn't put the foo2zjs-nonfree files into the right place as expected
by foo2zjs.  In the usual Debian world, the foo2zjs-nonfree maintainer
would write some fix-up scripts that would be a part of the that
package and it would be a non-issue since all of it would be in
non-free.

Again, for the sake of argument, let's assume that the foo2zjs-nonfree
maintainer is opposed to including those fix-ups directly into the
package for whatever reason (as an aside this sort of mimicks the
current upstream author's rejection of distro packaging of his
software).  So someone comes along and writes a foo2zjs-getmove
package, which moves the nonfree files into the right place that the
foo2zjs package needs.

Now, where does foo2zjs-getmove belong?  It only serves to support a
non-free component.  More importantly, what are the Depends and
Recommends of that package?  I would content that it would be a
"Depends: foo2zjs-nonfree", since the package itself can't do anything
without that.

Admittedly, this is a convoluted situation for normal Debian packages,
but it accurately mimicks the current situation if it were done with
packages rather than fetching scripts, and thus is valid as a
gedankenexperiment.

> I don't have anything new to say about that bug that I didn't say at the
> time.

I don't think you had commented at the time.

> I continue to believe that the current bug state is correct, and
> that your position on that bug is not correct, although I understand where
> your position comes from and I don't think it's unreasonable.

Opinions are malleable (wrong and right are all a matter of
perspective).  This is something sufficiently nuanced that I think its
worth sufficient pondering to really get it right.  If you haven't
spent much time pondering those nuances, it's easy to assume
perspective of the status quo.

>> The problem is that even though the lead-in uses the term "software",
>> the actual "must" requirements use the term "package".
>
>> Thus, a liberal reading of policy leads to the conclusion that if there
>> isn't an explicit dependency on a package, then it's ok to have a script
>> or plugin in main that makes use of non-free.
>
> Here is the complete text:
>
>    The main archive area comprises the Debian distribution. Only the
>    packages in this area are considered part of the distribution. None of
>    the packages in the main archive area require software outside of that
>    area to function. Anyone may use, share, modify and redistribute the
>    packages in this archive area freely[4].
>
>    Every package in main must comply with the DFSG (Debian Free Software
>    Guidelines).
>
>    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),
>
>    * must not be so buggy that we refuse to support them, and
>
>    * must meet all policy requirements presented in this manual.
>
> The words "in addition" have a specific meaning in English.  The bullet
> points do not replace all the text that comes before them.

Right, I wasn't trying to say that.  My point was more that the
lead-in paragraph as it is now is only descriptive, but given the
wording doesn't actually lay out any of particular requirements (more
so it lays out the ideals of main).  The requirements themselves
actually start with, "Every package in main must comply" then
continues with "In addition to" and then the bullets.  Those actually
binding sections never use the term "software", so the obvious
interpretation is that policy only places requirements on "packages",
and even more importantly seemingly only their control fields, not
their a

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

[Russ Allbery]

Michael Gilbert  writes:

> I understand this section very well, and even with that lead-in wording,
> I contend that sufficient ambiguity remains that additional clarity is
> needed.  Otherwise, it wouldn't have been so difficult to deal with bug
> #449497, which essentially turned into a wontfix.

No, that bug is a different argument (the one about what it means to
"require software").

I don't have anything new to say about that bug that I didn't say at the
time.  I continue to believe that the current bug state is correct, and
that your position on that bug is not correct, although I understand where
your position comes from and I don't think it's unreasonable.

> The problem is that even though the lead-in uses the term "software",
> the actual "must" requirements use the term "package".

> Thus, a liberal reading of policy leads to the conclusion that if there
> isn't an explicit dependency on a package, then it's ok to have a script
> or plugin in main that makes use of non-free.

Here is the complete text:

The main archive area comprises the Debian distribution. Only the
packages in this area are considered part of the distribution. None of
the packages in the main archive area require software outside of that
area to function. Anyone may use, share, modify and redistribute the
packages in this archive area freely[4].

Every package in main must comply with the DFSG (Debian Free Software
Guidelines).

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),

* must not be so buggy that we refuse to support them, and

* must meet all policy requirements presented in this manual.

The words "in addition" have a specific meaning in English.  The bullet
points do not replace all the text that comes before them.

I suppose we could add a "must" to the "None of the packages in the main
archive area require software outside of that area to function" sentence
with some rephrasing, if it would result in having fewer arguments about
this, but I really don't believe the meaning is unclear.

-- 
Russ Allbery (r...@debian.org)   



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

[Michael Gilbert]

On Tue, Mar 13, 2012 at 10:53 PM, Russ Allbery  wrote:
> Michael Gilbert  writes:
>
>> This is a bit off-topic for the bug report, but while you're thinking
>> about rewording this section, it may be prescient to consider
>> non-explicit dependencies.
>
>> For example, the getweb script in foo2jzs fetches non-free firmware
>> files, yet seems to be currently permissible in main given the current
>> policy wording since there is no "Depends or Recommends: > firmware files>" anywhere in the control file.
>
> This concern is addressed by the paragraph three higher, at the start of
> the section.
>
>    The main archive area comprises the Debian distribution. Only the
>    packages in this area are considered part of the distribution. None of
>    the packages in the main archive area require software outside of that
>    area to function.
>
> The non-free firmware fetched from elsewhere is clearly "software outside
> of that area."

I understand this section very well, and even with that lead-in
wording, I contend that sufficient ambiguity remains that additional
clarity is needed.  Otherwise, it wouldn't have been so difficult to
deal with bug #449497, which essentially turned into a wontfix.

The problem is that even though the lead-in uses the term "software",
the actual "must" requirements use the term "package".  Thus, a
liberal reading of policy leads to the conclusion that if there isn't
an explicit dependency on a package, then it's ok to have a script or
plugin in main that makes use of non-free.  I think that
interpretation violates the spirit of the policy.  Clearer wording
could fix this.

I would propose

--- a/text
+++ b/text2
@@ -1,4 +1,5 @@
-must not require or recommend a package outside of main for compilation or
+must not require or recommend software (including packages, plugins,
firmware, etc.)
+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),
+non-main package and must not include utilities that fetch non-main files),

Best wishes,
Mike



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

[Russ Allbery]

Michael Gilbert  writes:

> This is a bit off-topic for the bug report, but while you're thinking
> about rewording this section, it may be prescient to consider
> non-explicit dependencies.

> For example, the getweb script in foo2jzs fetches non-free firmware
> files, yet seems to be currently permissible in main given the current
> policy wording since there is no "Depends or Recommends:  firmware files>" anywhere in the control file.

This concern is addressed by the paragraph three higher, at the start of
the section.

The main archive area comprises the Debian distribution. Only the
packages in this area are considered part of the distribution. None of
the packages in the main archive area require software outside of that
area to function.

The non-free firmware fetched from elsewhere is clearly "software outside
of that area."

-- 
Russ Allbery (r...@debian.org)   



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

[Michael Gilbert]

On Thu, Jan 5, 2012 at 12:25 PM, Russ Allbery wrote:
> This is the bug concerning the wording in current Policy 2.2.1:
>
>    In addition, the packages in main
>
>     * must not require a package outside of main for compilation or
>       execution (thus, the package must not declare a "Depends",
>       "Recommends", or "Build-Depends" relationship on a non-main
>       package),
>
> There are two separate issues here.  One is the question of what to do
> about non-default alternatives (like Depends: unrar-free | unrar).  The
> other is that this is not a complete list of relevant fields.
>
> The second problem is, so far as I can tell, informative and completely
> non-controversial, so rather than have it blocked by the first problem,
> I've gone ahead and committed the following patch:
>
> diff --git a/policy.sgml b/policy.sgml
> index 79281e9..c1ff4b4 100644
> --- a/policy.sgml
> +++ b/policy.sgml
> @@ -489,9 +489,9 @@
>              
>                  must not require or recommend a package outside
>                  of main for compilation or execution (thus, the
> -                 package must not declare a "Depends", "Recommends", or
> -                 "Build-Depends" relationship on a non-main
> -                 package),
> +                 package must not declare a "Pre-Depends", "Depends",
> +                 "Recommends", "Build-Depends", or "Build-Depends-Indep"
> +                 relationship on a non-main package),
>              
>              
>                  must not be so buggy that we refuse to support them,

This is a bit off-topic for the bug report, but while you're thinking
about rewording this section, it may be prescient to consider
non-explicit dependencies.

For example, the getweb script in foo2jzs fetches non-free firmware
files, yet seems to be currently permissible in main given the current
policy wording since there is no "Depends or Recommends: " anywhere in the control file.

Anyway, something worth considering.  Perhaps this topic itself would
be better to start as a new bug report?

Best wishes,
Mike



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

[Raphael Hertzog]

On Tue, 13 Mar 2012, Wouter Verhelst wrote:
> No, that's not correct. If a package is already installed but a newever
> version is available, then this will be upgraded if the priority is 1.
> It just won't be selected for installation automatically.
> 
> This is how experimental works: packages in experimental have priority
> 1, so won't be installed automatically; but the will be upgraded if
> needs be.

I'm sorry but Carsten is right. I routinely add the snippet below
precisely because packages installed from experimental are not upgraded
from experimental without it.

Package: *
Pin: release experimental
Pin-Priority: 150

And it's also the reason why APT now supports a "ButAutomaticUpgrades: yes"
field to complement the "NotAutomatic: yes" field. The result is to have a
priority of 100 instead of 1 (backports.debian.org uses it).

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Pre-order a copy of the Debian Administrator's Handbook and help
liberate it: http://debian-handbook.info/liberation/



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

[Wouter Verhelst]

On Mon, Mar 12, 2012 at 06:19:47PM -0400, David Prévot wrote:
> Le 12/03/2012 13:44, Wouter Verhelst a écrit :
> > On Sat, Feb 25, 2012 at 01:56:17AM +0100, Carsten Hey wrote:
> 
> >> […] how a possible mechanism to let users choose between "always prefer
> >> free packages" and "follow the maintainer's recommendation, even it
> >> a non-free package is preferred" could look like.
> > 
> > That's easy:
> > 
> > Package: *
> > Pin: release c=non-free
> > Pin-Priority: 1
> > 
> > in a file in /etc/apt/preferences.d/
> 
> Please, don't provide such advice: that won't allow a non-free package
> to be updated automatically during a stable or security update.

No, that's not correct. If a package is already installed but a newever
version is available, then this will be upgraded if the priority is 1.
It just won't be selected for installation automatically.

This is how experimental works: packages in experimental have priority
1, so won't be installed automatically; but the will be upgraded if
needs be.

-- 
The volume of a pizza of thickness a and radius z can be described by
the following formula:

pi zz a



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

[David Prévot]

Le 12/03/2012 13:44, Wouter Verhelst a écrit :
> On Sat, Feb 25, 2012 at 01:56:17AM +0100, Carsten Hey wrote:

>> […] how a possible mechanism to let users choose between "always prefer
>> free packages" and "follow the maintainer's recommendation, even it
>> a non-free package is preferred" could look like.
> 
> That's easy:
> 
> Package: *
> Pin: release c=non-free
> Pin-Priority: 1
> 
> in a file in /etc/apt/preferences.d/

Please, don't provide such advice: that won't allow a non-free package
to be updated automatically during a stable or security update. Please
prefer using at least 100. Anyway, “The APT preferences file does not
affect the choice of instance, only the choice of version.” according to
apt_preferences(5).

Regards

David




signature.asc
Description: OpenPGP digital signature

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

[Wouter Verhelst]

On Sat, Feb 25, 2012 at 01:56:17AM +0100, Carsten Hey wrote:
> This reads like you ask if "main | non-free" should be allowed.  In my
> opinion, the question should rather be if it must be "main | non-free"
> or if both, "main | non-free" and "non-free | main", should be allowed
> and how a possible mechanism to let users choose between "always prefer
> free packages" and "follow the maintainer's recommendation, even it
> a non-free package is preferred" could look like.

That's easy:

Package: *
Pin: release c=non-free
Pin-Priority: 1

in a file in /etc/apt/preferences.d/

-- 
The volume of a pizza of thickness a and radius z can be described by
the following formula:

pi zz a



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

[Carsten Hey]

* Russ Allbery [2012-01-05 09:25 -0800]:
> This is the bug concerning the wording in current Policy 2.2.1:
>
> In addition, the packages in main
>
>  * must not require a package outside of main for compilation or
>execution (thus, the package must not declare a "Depends",
>"Recommends", or "Build-Depends" relationship on a non-main
>package),
>
> There are two separate issues here.  One is the question of what to do
> about non-default alternatives (like Depends: unrar-free | unrar).  The
> other is that this is not a complete list of relevant fields.

This reads like you ask if "main | non-free" should be allowed.  In my
opinion, the question should rather be if it must be "main | non-free"
or if both, "main | non-free" and "non-free | main", should be allowed
and how a possible mechanism to let users choose between "always prefer
free packages" and "follow the maintainer's recommendation, even it
a non-free package is preferred" could look like.  There is already
a way to express "never install non-free packages", i.e., vi
sources.list.

A bug that occurred because a Ubuntu maintainer assumed that "main
| universe" would not be not allowed (the wording in their policy
substitute was not clear back then) can be found at:

https://bugs.launchpad.net/bugs/704377

The question if "main | non-free" should be allowed is very similar to
the Ubuntu "main | universe" problem, except that the latter missed the
ideological part.


> The second problem is, so far as I can tell, informative and completely
> non-controversial, so rather than have it blocked by the first problem,
> I've gone ahead and committed the following patch:
>
> diff --git a/policy.sgml b/policy.sgml
> index 79281e9..c1ff4b4 100644
> --- a/policy.sgml
> +++ b/policy.sgml
> @@ -489,9 +489,9 @@
> 
> must not require or recommend a package outside
> of main for compilation or execution (thus, the
> -   package must not declare a "Depends", "Recommends", or
> -   "Build-Depends" relationship on a non-main
> -   package),
> +   package must not declare a "Pre-Depends", "Depends",
> +   "Recommends", "Build-Depends", or "Build-Depends-Indep"
> +   relationship on a non-main package),
> 
> 
> must not be so buggy that we refuse to support them,
>
> The remaining issue on this bug is then the discussion of what we want to
> say about alternative non-free dependencies.

In <87wrshvqh4@windlord.stanford.edu> you wrote that you filed a bug
about this second problem, mentioning the bug's number in this bug could
be useful.

http://www.debian.org/doc/debian-policy/ch-archive.html#s-main shows the
according part of the policy with above patch applied.  So one part of
this bug is fixed in policy and for the other one, there is an other bug
(additional to the already merged one)?  If this is true, this bug can
be closed or merged.


Carsten



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

[Russ Allbery]

This is the bug concerning the wording in current Policy 2.2.1:

In addition, the packages in main

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

There are two separate issues here.  One is the question of what to do
about non-default alternatives (like Depends: unrar-free | unrar).  The
other is that this is not a complete list of relevant fields.

The second problem is, so far as I can tell, informative and completely
non-controversial, so rather than have it blocked by the first problem,
I've gone ahead and committed the following patch:

diff --git a/policy.sgml b/policy.sgml
index 79281e9..c1ff4b4 100644
--- a/policy.sgml
+++ b/policy.sgml
@@ -489,9 +489,9 @@
  
  must not require or recommend a package outside
  of main for compilation or execution (thus, the
- package must not declare a "Depends", "Recommends", or
- "Build-Depends" relationship on a non-main
- package),
+ package must not declare a "Pre-Depends", "Depends",
+ "Recommends", "Build-Depends", or "Build-Depends-Indep"
+ relationship on a non-main package),
  
  
  must not be so buggy that we refuse to support them,

The remaining issue on this bug is then the discussion of what we want to
say about alternative non-free dependencies.

-- 
Russ Allbery (r...@debian.org)   



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

[Bill Allombert]

On Sat, Jul 24, 2010 at 09:43:34AM +0200, Steve Langasek wrote:
> On Thu, Jul 22, 2010 at 11:49:18AM +0200, Bill Allombert wrote:
> 
> > Where does policy define the concept of 'non-default alternative' for 
> > dependencies ?
> 
> This is implied by 7.5:
> 
>  If you want to specify which of a set of real packages should be the
>  default to satisfy a particular dependency on a virtual package, you
>  should list the real package as an alternative before the virtual one.
> 
> Do you think this needs to be made more explicit?

Well, this is close but, in the case we are discussing, a virtual package is not
involved (else a Provides would suffice, and the non-free package would better
be omitted).

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

[Russ Allbery]

Bill Allombert  writes:

> Where does policy define the concept of 'non-default alternative' for
> dependencies ?

Good point.  I think this should be more explicit, not just for this but
because it's a common topic elsewhere (such as with the default MTA) and
is something packagers should keep in mind when writing alternative
dependencies.  I've just filed a new bug against Policy for this
discussion, since it's somewhat independent.

-- 
Russ Allbery (r...@debian.org)   



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

[Steve Langasek]

On Thu, Jul 22, 2010 at 11:49:18AM +0200, Bill Allombert wrote:
> On Thu, Jul 22, 2010 at 12:45:49AM -0500, Raphael Geissert wrote:
> > On Monday 19 July 2010 11:26:38 Russ Allbery wrote:
> > > diff --git a/policy.sgml b/policy.sgml
> > > index 0b3c1a1..06c1fdc 100644
> > > --- a/policy.sgml
> > > +++ b/policy.sgml
> > > @@ -476,9 +476,12 @@
> > > 
> > > must not require a package outside of main
> > > for compilation or execution (thus, the package must
> > > -   not declare a "Depends", "Recommends", or
> > > -   "Build-Depends" relationship on a non-main
> > > -   package),
> > > +   not declare a Pre-Depends, Depends,
> > > +   Recommends, Build-Depends,
> > > +   or Build-Depends-Indep relationship on a
> > > +   non-main package unless that package is only
> > > +   listed as a non-default alternative for a package
> > > +   in main > > 
> > > 
> > > must not be so buggy that we refuse to support them,

> Where does policy define the concept of 'non-default alternative' for 
> dependencies ?

This is implied by 7.5:

 If you want to specify which of a set of real packages should be the
 default to satisfy a particular dependency on a virtual package, you
 should list the real package as an alternative before the virtual one.

Do you think this needs to be made more explicit?

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

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

[Russ Allbery]

Bill Allombert  writes:

> Does that allow to add dependencies on packages that exist only in
> non-Debian repositories as 'non-default alternative' ?

I hope so; it's common practice for packages that require out-of-tree
kernel modules, for instance.

-- 
Russ Allbery (r...@debian.org)   



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

[Bill Allombert]

On Mon, Jul 19, 2010 at 09:26:38AM -0700, Russ Allbery wrote:
> diff --git a/policy.sgml b/policy.sgml
> index 0b3c1a1..06c1fdc 100644
> --- a/policy.sgml
> +++ b/policy.sgml
> @@ -476,9 +476,12 @@
> 
> must not require a package outside of main
> for compilation or execution (thus, the package must
> -   not declare a "Depends", "Recommends", or
> -   "Build-Depends" relationship on a non-main
> -   package),
> +   not declare a Pre-Depends, Depends,
> +   Recommends, Build-Depends,
> +   or Build-Depends-Indep relationship on a
> +   non-main package unless that package is only
> +   listed as a non-default alternative for a package
> +   in main 
> 
> must not be so buggy that we refuse to support them,

Does that allow to add dependencies on packages that exist only in non-Debian 
repositories
as 'non-default alternative' ?

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

[Russ Allbery]

Bill Allombert  writes:

> For my part I would prefer to keep the current policy and use Provides
> for non-free software.

I think this would be worse from the perspective of not accidentally
getting non-free software.  Isn't the package installed by dependency when
multiple packages Provide that package non-deterministic?  Whereas if you
list the free dependency first, you always get it by default if it's
satisfiable.

-- 
Russ Allbery (r...@debian.org)   



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

[Raphael Geissert]

On Thursday 22 July 2010 04:49:18 Bill Allombert wrote:
> For my part I would prefer to keep the current policy and use Provides for
> non-free software.

I see two problems with that, and I actually object to that idea:

a) Provides means, in this case the non-free package, has a compatible 
interface to that of the package in main. This might not always be true. Take 
mailscanner as an example: it has support for multiple different antivirus 
software and they obviously don't provide the same interface (and some of them 
are available as .deb packages.)

b) In your other email (#17 of this report) you claim that:
* "Debian would not advertize non-free software," [1] and
* that "non-free is not part of Debian."
So, how can you distinguish a package not in Debian from a non-free package? 
(which, as you said, is not part of Debian -- redundancy intended.)
There are also cases where a given package is no longer free, and what usually 
happens is that a free fork is created under a different name. In those cases 
we would still "advertise" the non-free software for at least some time (e.g. 
during the lifetime of stable and oldstable, etc.)

[1] By the way, you were asked for references or pointers but you haven't 
provided any. It would be important for this discussion to have them, if there 
is any.

Cheers,
-- 
Raphael Geissert - Debian Developer
www.debian.org - get.debian.net


signature.asc
Description: This is a digitally signed message part.

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

[Bill Allombert]

On Thu, Jul 22, 2010 at 12:45:49AM -0500, Raphael Geissert wrote:
> On Monday 19 July 2010 11:26:38 Russ Allbery wrote:
> > diff --git a/policy.sgml b/policy.sgml
> > index 0b3c1a1..06c1fdc 100644
> > --- a/policy.sgml
> > +++ b/policy.sgml
> > @@ -476,9 +476,12 @@
> >   
> >   must not require a package outside of main
> >   for compilation or execution (thus, the package must
> > - not declare a "Depends", "Recommends", or
> > - "Build-Depends" relationship on a non-main
> > - package),
> > + not declare a Pre-Depends, Depends,
> > + Recommends, Build-Depends,
> > + or Build-Depends-Indep relationship on a
> > + non-main package unless that package is only
> > + listed as a non-default alternative for a package
> > + in main >   
> >   
> >   must not be so buggy that we refuse to support them,

Where does policy define the concept of 'non-default alternative' for 
dependencies ?

For my part I would prefer to keep the current policy and use Provides for 
non-free
software.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

[Steve Langasek]

On Mon, Jul 19, 2010 at 09:26:38AM -0700, Russ Allbery wrote:
> Steve Langasek  writes:

> > This particular wording allows for the non-free package to be first in
> > the list of alternatives, which I think is clearly incorrect.  The
> > intent AIUI is to avoid installation of a package in main ever causing a
> > non-free package to be pulled in automatically, regardless of whether
> > non-free is enabled in sources.list.

> > So I would instead suggest writing this as:

> >   unless this package is listed as a non-default alternative to a package in
> >   main

> Good point.  Here's updated wording, which starts from yours and tweaks it
> a little bit to try to make it even more explicit.

> diff --git a/policy.sgml b/policy.sgml
> index 0b3c1a1..06c1fdc 100644
> --- a/policy.sgml
> +++ b/policy.sgml
> @@ -476,9 +476,12 @@
> 
> must not require a package outside of main
> for compilation or execution (thus, the package must
> -   not declare a "Depends", "Recommends", or
> -   "Build-Depends" relationship on a non-main
> -   package),
> +   not declare a Pre-Depends, Depends,
> +   Recommends, Build-Depends,
> +   or Build-Depends-Indep relationship on a
> +   non-main package unless that package is only
> +   listed as a non-default alternative for a package
> +   in main 
> 
> must not be so buggy that we refuse to support them,

Seconded.

Cheers,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

[Raphael Geissert]

On Monday 19 July 2010 11:26:38 Russ Allbery wrote:
> diff --git a/policy.sgml b/policy.sgml
> index 0b3c1a1..06c1fdc 100644
> --- a/policy.sgml
> +++ b/policy.sgml
> @@ -476,9 +476,12 @@
> 
> must not require a package outside of main
> for compilation or execution (thus, the package must
> -   not declare a "Depends", "Recommends", or
> -   "Build-Depends" relationship on a non-main
> -   package),
> +   not declare a Pre-Depends, Depends,
> +   Recommends, Build-Depends,
> +   or Build-Depends-Indep relationship on a
> +   non-main package unless that package is only
> +   listed as a non-default alternative for a package
> +   in main 
> 
> must not be so buggy that we refuse to support them,

Seconded.

Cheers,
-- 
Raphael Geissert - Debian Developer
www.debian.org - get.debian.net


signature.asc
Description: This is a digitally signed message part.

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

[Russ Allbery]

Steve Langasek  writes:

> This particular wording allows for the non-free package to be first in
> the list of alternatives, which I think is clearly incorrect.  The
> intent AIUI is to avoid installation of a package in main ever causing a
> non-free package to be pulled in automatically, regardless of whether
> non-free is enabled in sources.list.

> So I would instead suggest writing this as:

>   unless this package is listed as a non-default alternative to a package in
>   main

Good point.  Here's updated wording, which starts from yours and tweaks it
a little bit to try to make it even more explicit.

diff --git a/policy.sgml b/policy.sgml
index 0b3c1a1..06c1fdc 100644
--- a/policy.sgml
+++ b/policy.sgml
@@ -476,9 +476,12 @@
  
  must not require a package outside of main
  for compilation or execution (thus, the package must
- not declare a "Depends", "Recommends", or
- "Build-Depends" relationship on a non-main
- package),
+ not declare a Pre-Depends, Depends,
+ Recommends, Build-Depends,
+ or Build-Depends-Indep relationship on a
+ non-main package unless that package is only
+ listed as a non-default alternative for a package
+ in main
  
  must not be so buggy that we refuse to support them,

-- 
Russ Allbery (r...@debian.org)   



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

[Steve Langasek]

Hi Bill,

On Wed, Jul 14, 2010 at 02:15:19PM +0200, Bill Allombert wrote:

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

That has never been my understanding, but I wasn't around when the original
wording was drafted.  Do you have any pointers to list archives showing
discussions of this particular issue?

If it was really intended by the project in the past that packages in main
avoid any mention of non-free or contrib packages, even when these will not
be installed by default[1], then this seems to be a question for a GR and
not a matter of technical policy.  But it's news to me that this was ever
the intent.

Cheers,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org

[1] BTW, what is the distinction you draw here between a non-free package
listed as a non-default alternative Depends, and a non-free package listed
in Suggests?  The latter has been permitted forever; indeed, the standard
fix for a package in main with a wrong Recommends on non-free is to demote
this relationship to a Suggests!



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

[Steve Langasek]

On Wed, Jul 14, 2010 at 09:23:02AM -0700, Russ Allbery wrote:
> diff --git a/policy.sgml b/policy.sgml
> index 3e99099..9fe7158 100644
> --- a/policy.sgml
> +++ b/policy.sgml
> @@ -476,9 +476,11 @@
> 
> must not require a package outside of main
> for compilation or execution (thus, the package must
> -   not declare a "Depends", "Recommends", or
> -   "Build-Depends" relationship on a non-main
> -   package),
> +   not declare a Pre-Depends, Depends,
> +   Recommends, Build-Depends,
> +   or Build-Depends-Indep relationship on a
> +   non-main package unless a package
> +   in main is listed as an alternative),
> 
> 
> must not be so buggy that we refuse to support them,

This particular wording allows for the non-free package to be first in the
list of alternatives, which I think is clearly incorrect.  The intent AIUI
is to avoid installation of a package in main ever causing a non-free
package to be pulled in automatically, regardless of whether non-free is
enabled in sources.list.

So I would instead suggest writing this as:

  unless this package is listed as a non-default alternative to a package in
  main

Cheers,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

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

[Charles Plessy]

Dear all,

After reading the answer of Russ in message #34, that because of virtual
packages the dependancy graph is not closed anyway, and (in answer to Bill's
comments message #17) considering that non-free packages are anyway advertised
in the main section through Suggests dependancies, I second the patch in
message #22.

Have a nice day,

-- 
Charles



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

[Russ Allbery]

Charles Plessy  writes:

> I also have mixed feelings about aligning Policy on current practices:
> on systems where the contrib and non-free archives are not enabled, this
> brings unavailable packages in the part of the dependancy graph that is
> supposed to be closed in stable releases. However, I admit that the
> wording of the release goal would allow to list unavailable packages as
> alternatives.

Note that we don't have a closed dependency graph anyway due to virtual
packages.  See, for instance, the Recommends in openafs-client.
openafs-modules2 is not provided by any package in the archive; it's
provided by the Debian packages that are built from
openafs-modules-source.

-- 
Russ Allbery (r...@debian.org)   



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

[Charles Plessy]

Le Wed, Jul 14, 2010 at 09:23:02AM -0700, Russ Allbery a écrit :
> 
> diff --git a/policy.sgml b/policy.sgml
> index 3e99099..9fe7158 100644
> --- a/policy.sgml
> +++ b/policy.sgml
> @@ -476,9 +476,11 @@
> 
> must not require a package outside of main
> for compilation or execution (thus, the package must
> -   not declare a "Depends", "Recommends", or
> -   "Build-Depends" relationship on a non-main
> -   package),
> +   not declare a Pre-Depends, Depends,
> +   Recommends, Build-Depends,
> +   or Build-Depends-Indep relationship on a
> +   non-main package unless a package
> +   in main is listed as an alternative),
> 
> 
> must not be so buggy that we refuse to support them,

Dear all,

I also have mixed feelings about aligning Policy on current practices: on
systems where the contrib and non-free archives are not enabled, this brings
unavailable packages in the part of the dependancy graph that is supposed to be
closed in stable releases. However, I admit that the wording of the release
goal would allow to list unavailable packages as alternatives.

Have a nice day,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

[Russ Allbery]

Bill Allombert  writes:
> On Tue, Jun 29, 2010 at 10:31:57AM -0700, Russ Allbery wrote:

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

Okay.  If there's disagreement, then we may as well use a somewhat more
formal procedure.  I've reverted the change while we discuss this.

> Part of the "non-free is not part of Debian" deal was that Debian (main)
> would not "advertize" non-free software.

I believe this is exactly backwards from history.  My understanding is
that our refusal to abide by this rule is the reason why the FSF removed
Debian from its list of advertised Linux distributions.  And regardless,
I've never seen anywhere in the project documents that we say we won't
advertise non-free software.

We've allowed alternative dependencies including non-free software in
Debian for forever (certainly for as long as I've been part of the
project), so if your reading is correct, Policy is inconsistent with
reality and existing packages are buggy.  I believe Policy is wrong and
the packages are correct, and therefore propose the following fix, which
also specifically mentions the build relationship fields:

diff --git a/policy.sgml b/policy.sgml
index 3e99099..9fe7158 100644
--- a/policy.sgml
+++ b/policy.sgml
@@ -476,9 +476,11 @@
  
  must not require a package outside of main
  for compilation or execution (thus, the package must
- not declare a "Depends", "Recommends", or
- "Build-Depends" relationship on a non-main
- package),
+ not declare a Pre-Depends, Depends,
+ Recommends, Build-Depends,
+ or Build-Depends-Indep relationship on a
+ non-main package unless a package
+ in main is listed as an alternative),
  
  
  must not be so buggy that we refuse to support them,

-- 
Russ Allbery (r...@debian.org)   



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

[Bill Allombert]

On Tue, Jun 29, 2010 at 10:31:57AM -0700, Russ Allbery wrote:
> Raphael Geissert  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. 

Imagine a large red swirl here. 


signature.asc
Description: Digital signature

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

[Russ Allbery]

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

diff --git a/policy.sgml b/policy.sgml
index 3e99099..9fe7158 100644
--- a/policy.sgml
+++ b/policy.sgml
@@ -476,9 +476,11 @@
  
  must not require a package outside of main
  for compilation or execution (thus, the package must
- not declare a "Depends", "Recommends", or
- "Build-Depends" relationship on a non-main
- package),
+ not declare a Pre-Depends, Depends,
+ Recommends, Build-Depends,
+ or Build-Depends-Indep relationship on a
+ non-main package unless a package
+ in main is listed as an alternative),
  
  
  must not be so buggy that we refuse to support them,

-- 
Russ Allbery (r...@debian.org)   



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

[Raphael Geissert]

Package: debian-policy
Version: 3.8.4
Tags: patch

Hi,

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

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

Proposed wording change for a) is:

must not require a package outside of main
for compilation or execution [-(thus,-] {+(e.g.,+} the package must
not declare a {+"Pre-Depends",+} "Depends", "Recommends",
{+"Build-Depends",+} or
[-"Build-Depends"-] {+"Build-Depends-Indep"+} relationship
on a non-main package),

For b):

not declare a "Depends", "Recommends", or
"Build-Depends" relationship on a non-main
[-package),-]
{+package as the first alternative, if any),+}

Attached mbox contains the commit with both changes combined.

Cheers,
-- 
Raphael Geissert - Debian Developer
www.debian.org - get.debian.net


section-2.2.1.mbox
Description: application/mbox


signature.asc
Description: This is a digitally signed message part.