Bug#587279: debian-policy: section 2.2.1 needs some tweaking
Russ Allbery r...@debian.org 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 r...@debian.org 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 @@ p The emmain/em archive area comprises the Debian distribution. Only the packages in this area are considered - part of the distribution. None of the packages in - the emmain/em archive area require software outside of - that area to function. Anyone may use, share, modify and - redistribute the packages in this archive area - freelyfootnote + part of the distribution. + /p + + pEvery package in emmain/em must be freefootnote See url id=http://www.debian.org/intro/free; name=What Does Free Mean? for more about what we mean by free software. - /footnote. + /footnote for anyone to use, share, modify, and redistribute, + and must function without requiring works outside of + the emmain/em area. /p p 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
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 used to play non-free ROMs but can also play the -- often nearly nonexistent -- free ROMs). In other words,
Bug#587279: debian-policy: section 2.2.1 needs some tweaking
Michael Gilbert michael.s.gilb...@gmail.com 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) http://www.eyrie.org/~eagle/ -- 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
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
Michael Gilbert michael.s.gilb...@gmail.com 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) http://www.eyrie.org/~eagle/ -- 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
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
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
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
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 @@ item must not require or recommend a package outside of emmain/em for compilation or execution (thus, the - package must not declare a Depends, Recommends, or - Build-Depends relationship on a non-emmain/em - package), + package must not declare a Pre-Depends, Depends, + Recommends, Build-Depends, or Build-Depends-Indep + relationship on a non-emmain/em package), /item item 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: external firmware files 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
Michael Gilbert michael.s.gilb...@gmail.com 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: external 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) http://www.eyrie.org/~eagle/ -- 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
On Tue, Mar 13, 2012 at 10:53 PM, Russ Allbery r...@debian.org wrote: Michael Gilbert michael.s.gilb...@gmail.com 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: external 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
Michael Gilbert michael.s.gilb...@gmail.com 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) http://www.eyrie.org/~eagle/ -- 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
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 actual components (giving things like getweb a pass). I suppose we could add a
Bug#587279: debian-policy: section 2.2.1 needs some tweaking
Michael Gilbert michael.s.gilb...@gmail.com 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) http://www.eyrie.org/~eagle/ -- 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
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
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
* 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 @@ item must not require or recommend a package outside of emmain/em for compilation or execution (thus, the - package must not declare a Depends, Recommends, or - Build-Depends relationship on a non-emmain/em - package), + package must not declare a Pre-Depends, Depends, + Recommends, Build-Depends, or Build-Depends-Indep + relationship on a non-emmain/em package), /item item 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
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 @@ item must not require or recommend a package outside of emmain/em for compilation or execution (thus, the - package must not declare a Depends, Recommends, or - Build-Depends relationship on a non-emmain/em - package), + package must not declare a Pre-Depends, Depends, + Recommends, Build-Depends, or Build-Depends-Indep + relationship on a non-emmain/em package), /item item 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) http://www.eyrie.org/~eagle/ -- 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
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. ballo...@debian.org 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
Bill Allombert bill.allomb...@math.u-bordeaux1.fr 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) http://www.eyrie.org/~eagle/ -- 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
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 @@ item must not require a package outside of emmain/em for compilation or execution (thus, the package must - not declare a Depends, Recommends, or - Build-Depends relationship on a non-emmain/em - package), + not declare a ttPre-Depends/tt, ttDepends/tt, + ttRecommends/tt, ttBuild-Depends/tt, + or ttBuild-Depends-Indep/tt relationship on a + non-emmain/em package unless that package is only + listed as a non-default alternative for a package + in emmain/em), /item item 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
On Mon, Jul 19, 2010 at 09:26:38AM -0700, Russ Allbery wrote: Steve Langasek vor...@debian.org 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 emmain/em 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 @@ item must not require a package outside of emmain/em for compilation or execution (thus, the package must - not declare a Depends, Recommends, or - Build-Depends relationship on a non-emmain/em - package), + not declare a ttPre-Depends/tt, ttDepends/tt, + ttRecommends/tt, ttBuild-Depends/tt, + or ttBuild-Depends-Indep/tt relationship on a + non-emmain/em package unless that package is only + listed as a non-default alternative for a package + in emmain/em), /item item 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
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 @@ item must not require a package outside of emmain/em for compilation or execution (thus, the package must - not declare a Depends, Recommends, or - Build-Depends relationship on a non-emmain/em - package), + not declare a ttPre-Depends/tt, ttDepends/tt, + ttRecommends/tt, ttBuild-Depends/tt, + or ttBuild-Depends-Indep/tt relationship on a + non-emmain/em package unless that package is only + listed as a non-default alternative for a package + in emmain/em), /item item 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. ballo...@debian.org 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
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 bill.allomb...@math.u-bordeaux1.fr 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) http://www.eyrie.org/~eagle/ -- 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
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 @@ item must not require a package outside of emmain/em for compilation or execution (thus, the package must - not declare a Depends, Recommends, or - Build-Depends relationship on a non-emmain/em - package), + not declare a ttPre-Depends/tt, ttDepends/tt, + ttRecommends/tt, ttBuild-Depends/tt, + or ttBuild-Depends-Indep/tt relationship on a + non-emmain/em package unless that package is only + listed as a non-default alternative for a package + in emmain/em), /item item 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. ballo...@debian.org 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
Bill Allombert bill.allomb...@math.u-bordeaux1.fr 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) http://www.eyrie.org/~eagle/ -- 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
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 @@ item must not require a package outside of emmain/em for compilation or execution (thus, the package must - not declare a Depends, Recommends, or - Build-Depends relationship on a non-emmain/em - package), + not declare a ttPre-Depends/tt, ttDepends/tt, + ttRecommends/tt, ttBuild-Depends/tt, + or ttBuild-Depends-Indep/tt relationship on a + non-emmain/em package unless that package is only + listed as a non-default alternative for a package + in emmain/em), /item item 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
Steve Langasek vor...@debian.org 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 emmain/em 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 @@ item must not require a package outside of emmain/em for compilation or execution (thus, the package must - not declare a Depends, Recommends, or - Build-Depends relationship on a non-emmain/em - package), + not declare a ttPre-Depends/tt, ttDepends/tt, + ttRecommends/tt, ttBuild-Depends/tt, + or ttBuild-Depends-Indep/tt relationship on a + non-emmain/em package unless that package is only + listed as a non-default alternative for a package + in emmain/em), /item item must not be so buggy that we refuse to support them, -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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
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 @@ item must not require a package outside of emmain/em for compilation or execution (thus, the package must - not declare a Depends, Recommends, or - Build-Depends relationship on a non-emmain/em - package), + not declare a ttPre-Depends/tt, ttDepends/tt, + ttRecommends/tt, ttBuild-Depends/tt, + or ttBuild-Depends-Indep/tt relationship on a + non-emmain/em package unless a package + in emmain/em is listed as an alternative), /item item 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 emmain/em 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
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
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
On Tue, Jun 29, 2010 at 10:31:57AM -0700, Russ Allbery wrote: Raphael Geissert geiss...@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. ballo...@debian.org Imagine a large red swirl here. signature.asc Description: Digital signature
Bug#587279: debian-policy: section 2.2.1 needs some tweaking
Bill Allombert bill.allomb...@math.u-bordeaux1.fr 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 @@ item must not require a package outside of emmain/em for compilation or execution (thus, the package must - not declare a Depends, Recommends, or - Build-Depends relationship on a non-emmain/em - package), + not declare a ttPre-Depends/tt, ttDepends/tt, + ttRecommends/tt, ttBuild-Depends/tt, + or ttBuild-Depends-Indep/tt relationship on a + non-emmain/em package unless a package + in emmain/em is listed as an alternative), /item item must not be so buggy that we refuse to support them, -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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
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 @@ item must not require a package outside of emmain/em for compilation or execution (thus, the package must - not declare a Depends, Recommends, or - Build-Depends relationship on a non-emmain/em - package), + not declare a ttPre-Depends/tt, ttDepends/tt, + ttRecommends/tt, ttBuild-Depends/tt, + or ttBuild-Depends-Indep/tt relationship on a + non-emmain/em package unless a package + in emmain/em is listed as an alternative), /item item 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
Charles Plessy ple...@debian.org 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) http://www.eyrie.org/~eagle/ -- 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 geiss...@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. diff --git a/policy.sgml b/policy.sgml index 3e99099..9fe7158 100644 --- a/policy.sgml +++ b/policy.sgml @@ -476,9 +476,11 @@ item must not require a package outside of emmain/em for compilation or execution (thus, the package must - not declare a Depends, Recommends, or - Build-Depends relationship on a non-emmain/em - package), + not declare a ttPre-Depends/tt, ttDepends/tt, + ttRecommends/tt, ttBuild-Depends/tt, + or ttBuild-Depends-Indep/tt relationship on a + non-emmain/em package unless a package + in emmain/em is listed as an alternative), /item item must not be so buggy that we refuse to support them, -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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
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 emmain/em
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-emmain/em package),
For b):
not declare a Depends, Recommends, or
Build-Depends relationship on a non-emmain/em
[-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.
