Bug#248809: rwba 0r

[Starla Krystina]

r8y



-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4c77af61.5acf4...@unimstores.com

Processed: user debian-pol...@packages.debian.org, limit package to debian-policy, usertagging 488214 ...

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> user debian-pol...@packages.debian.org
Setting user to debian-pol...@packages.debian.org (was r...@debian.org).
> limit package debian-policy
Limiting to bugs with field 'package' containing at least one of 'debian-policy'
Limit currently set to 'package':'debian-policy'

> usertags 488214 = normative
Bug#488214: make mailx a registered virtual package name
Usertags were: normative.
Usertags are now: normative.
> tags 488214 = pending
Bug #488214 [debian-policy] make mailx a registered virtual package name
Added tag(s) pending; removed tag(s) patch.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
488214: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=488214
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/handler.s.c.12829285521131.transcr...@bugs.debian.org

Bug#488214: make mailx a registered virtual package name

[Russ Allbery]

"Giacomo A. Catenazzi"  writes:
> On 21.08.2010 08:36, Raphael Hertzog wrote:
>> On Fri, 20 Aug 2010, Russ Allbery wrote:

>>> diff --git a/virtual-package-names-list.txt b/virtual-package-names-list.txt
>>> index 9ba66e5..2308d39 100644
>>> --- a/virtual-package-names-list.txt
>>> +++ b/virtual-package-names-list.txt
>>> @@ -123,6 +123,8 @@ News and Mail
>>>imap-server an IMAP mail server
>>>mail-reader a mail user agent (e.g. Pine, Elm, mailx,&c)
>>>mail-transport-agenta mail transport agent (e.g. Smail, Sendmail,&c)
>>> + mailx   a /usr/bin/mailx binary that provides at least
>>> + the POSIX mailx interface (*)
>>>news-reader a news reader (e.g. trn, tin,&c)
>>>news-transport-system   a local news system (e.g. INN, C News or B News)
>>>pgp a version of PGP (International or US)
>>
>> Seconded.

> seconded

Thanks!  This has now been merged for the next release.

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



-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/877hjc56pa@windlord.stanford.edu

Bug#594274: debian-policy: Don't track generated README documents in VCS

[Russ Allbery]

Ben Finney  writes:

> The VCS repository for ‘debian-policy’ contains a source document
> ‘README.org’ along with rules to render that to the destination
> documents.

> However, the VCS repository also contains the rendered documents
> themselves. Those should not be tracked in VCS; instead, they should
> be generated from source as needed.

This was intentional when those files were introduced since rebuilding
them requires Emacs, and the concern was that not everyone who worked on
Policy would want to have Emacs installed.  If that's no longer a concern,
I can remove the generated files and build them from debian/rules by
default.

In the long run, if we're standardizing on Docbook, they should also be
converted to Docbook.

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



--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/8739u056my@windlord.stanford.edu

Bug#106073: recommend to install documentation into /usr/share/doc//

[Russ Allbery]

Thank you for writing this up!

Ben Finney  writes:

> There seems to be consensus on doing this, so I've made a patch
> (attached to this message) which implements that recommendation.

I'm inclined to second this, although I wonder if should is too strong at
this point and we should instead allow for either method but document that
using the same directory as the "parent" package is preferred.  That would
avoid the instantly buggy issue but still set up a transition over time.

We'll need a Lintian tag, etc., to actually get everything moved over.

I also agree with Bill that it might be useful to say that one should have
a symlink or symlinks in the /usr/share/doc/package-doc directory pointing
to the docs in the other directory (or vice versa; it doesn't really
matter which direction the linking goes).  That would also make the
transition easier.

> @@ -9524,16 +9544,16 @@
> via HTML.
>  
>   
> -   If your package comes with extensive documentation in a
> +   If the package comes with extensive documentation in a
> markup format that can be converted to various other formats
> you should if possible ship HTML versions in a binary
> -   package, in the directory
> -   /usr/share/doc/appropriate-package or
> -   its subdirectories.
> -   The rationale: The important thing here is that HTML
> -   docs should be available in some package, not
> -   necessarily in the main binary package.
> +   package.
> +   Rationale: The important thing here is that HTML
> +   documentation should be available from some
> +   binary package.
> 
> +   The documentation must be installed as specified in
> +   .
>   
>  
>   

This part is fairly confusing, although that's not a new problem, just
highlighted by the changes nearby.

I think that last "must" should be a "should".

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



-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87y6bs3rok@windlord.stanford.edu

Bug#106073: recommend to install documentation into /usr/share/doc//

[Russ Allbery]

Andrew McMillan  writes:

> My personal preference would be to encourage -doc packages to install
> their files into /usr/share/doc//docs - including their
> internal administrivia.

That would break Lintian, apt-listchanges, probably the DAK processing
scripts, and anything else that looks at copyright and changelog in binary
packages.  I don't think it's worth it to make that change.

> While this is not current practice, I'm not convinced that current
> practice has evolved into what was suggested in 2003 either.

Right now, I'm seeing a real mix of behavior, with some packages
installing all the documentation into the -doc package's /usr/share/doc
(probably in part because that's easier) and others installing it into the
parent package, some with symlinks and some without.  As a result, right
now one cannot easily find the documentation in any standardized place.

> I also remember as a user hunting for these documents the first time or
> two when I had installed the -doc package and it slowly dawning on me
> that they weren't anywhere in /usr/share/doc/, and I think that
> breaks the principal of least surprise, for everyone except long-time,
> hard-core Debianista.

Yeah, that's what Ben's writeup would fix, and I agree that's worth
fixing.

> Those points are justifications for both proposals, of course, and I
> guess that one reason for retaining the administrivia
> in /usr/share/doc/-doc might be that there are tools that
> expect to find it there.  Is that the case?

Yup.

> I don't think I ever do more than refer to them by hand, and either
> proposed change can probably be codified in some small number of
> scripts.

I don't think the change proposed here requires changing any scripts,
although it will require changing a bunch of packages (and a change to
debhelper to make it easier to install docs into the right place would be
useful).

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



-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87tymg3rim@windlord.stanford.edu

Bug#593909: debian-policy: Clarifications about the syntax of Debian control files.

[Russ Allbery]

Charles Plessy  writes:

> Non-wrappable field values
> --

> §5.1 contains the following paragraph:

>   In fields where it is specified that lines may not wrap, only a single
>   line of data is allowed and whitespace is not significant in a field
>   body. Whitespace must not appear inside names (of packages,
>   architectures, files or anything else) or version numbers, or between
>   the characters of multi-character version relationships.

What this paragraph means by "wrap" is "may span multiple lines," and it's
also really not correct about whitespace.  I think what this paragraph
should say is something like:

In fields where the value may not span multiple lines, the amount of
whitespace in the field body is not significant.  Any amount of
whitespace is equivalent to a single space.  Whitespace must not
appear inside names (of packages, architectures, files, or anything
else) or version numbers, or between the characters of multi-character
versoin relationships.

> The Architecture and Closes fields seem to follow this convention,
> without referring to it (they do not specify that ‘lines may not
> wrap’). The Distribution also allows a list of values, but not for the
> Debian archive.  The Binary field also contains a space-separated list
> of items, but is wrappable.

"Wrap" is a very bad term to use here, since it implies something about
presentation.  That's not the intention of the paragraph; rather, it's
talking about whether or not the field body may contain newlines.

> Many other fields are single line, but they do not contain a list of
> space-separated items. For instance, the Maintainer and Urgencey fields.

Indeed.  But I don't think we imply that it does.

> Policy chapter 5 contains only two times the word “wrap”, one in the
> above quotation and one in the context of the Description field
> (§5.6.13), in the part that explain how to specify verbatim parts in
> extened descriptions.

The second use is correct, and we should definitely fix the first.

> I am working on DEP-5, which aims at using the Debian control file
> format, I have the feeling that the paragraph that I quoted above makes
> it more difficult to describe how text can be wrapped or not on
> multi-line fields. Unless it has a crucial role that I have overlooked,
> I propose its supppression.

It's saying a bunch of things that aren't said elsewhere, so I don't think
there's any way that we could just drop it.

> Ordering of the paragraphs
> --

> I always had the impression that the Debian control files had one header
> paragraph, followed by other paragraphs that were not ordered. If it is
> not the case, that is: if parsers are required to remember the order of
> the paragraphs.  I think that it would be useful to write it in §5.1.

In that case, yes, we should say that the order of paragraphs is
significant, since indeed it always has been.  Probably just by adding the
sentence "The order of paragraphs in the control file is significant" to
the end of the first paragraph.

> Line escape and paragraph separators
> 

> “Blank lines, or lines consisting only of spaces and tabs, are not
> allowed within field values or between fields”. The Description and
> Changes fields introduce a convention to escape blank lines,
> representing them by a space followed by a dot. How describing this
> convention directly in §5.1?

Sure, that sounds like a good idea.

> Also, while submitting this bug, I found #501930 about paragraph
> separation.  If the outcome of this discussion is a patch, I propose to
> let it addres #501930 as well, by adding “lines consisting only of
> spaces and tabs” to the second sentence of §5.1.

I'm torn on that bug.  The ideal thing to do there, I think, is to say
that lines consisting solely of spaces and tabs are a syntax error and are
not allowed, but parsers may accept them as paragraph separators.  (Be
conservative in what you generate and liberal in what you accept.)  I'm
concerned that we have code out there that doesn't recognize them as
paragraph separators, and explicitly allowing them will make that code
buggy.

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



--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87pqx43r4m@windlord.stanford.edu

Bug#593909: debian-policy: Clarifications about the syntax of Debian control files.

[Russ Allbery]

Charles Plessy  writes:

> to this list I would like to add comment lines. Currently they are
> described in §5.2 (5.2 Source package control files -- debian/control),
> as an additional syntax, which strongly suggests that they are allowed
> in this file only.

That's correct; they're only allowed in source package control files.

> Independantly of whether this is confirmed or not, this syntactic
> information would rather belong to §5.1, that defines the syntax of the
> control files, instead of §5.2, which like the next chapters §5.3–6
> lists the fields allowed in the different Debian control files. I would
> therefore propose to have in §5.1:

>   Lines starting with # without any preceding whitespace are ‘comments
>   lines’ and are ignored, even in the middle of continuation lines for a
>   multiline field. They do not end a multiline field.

> If comment lines are only allowed in source package control files, we could
> add:

>   The use of such comments must be allowed on a per-file basis.

I would rather just say "These comments are only permitted in source
package control files (debian/control)," and preferrably say
that as the first sentence of the paragraph rather than the last.  I can't
imagine us ever adding support for them anywhere else.

> And then in §5.2:

>   Comment lines are allowed.

This is fine.

> The benefit of this is that it concentrates in §5.1 all the instructions
> to write a basic parser for Debian control files.

Yes, that's a good idea.

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



--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87lj7s3r1h@windlord.stanford.edu

Bug#594542: debian-policy: add descriptions for main, contrib, and non-free archive areas

[Russ Allbery]

CJ Fearnley  writes:

> Especially since the main, contrib, and non-free archive areas are not
> described anywhere else (as far as I can tell), it would be helpful if
> some descriptive text were added to explain the intent of policy.  I
> suggest the following in the hopes that others will flesh out the
> descriptions to be more accurate and complete than my first cut:

> 2.2.1 The main archive area

> The main archive area is where the core of the Debian GNU/Linux system
> lives.  All of the software in main can stand alone as a fully
> operational system without any software from contrib or non-free.  The
> software included in main is vetted to ensure compliance with policy and
> the DFSG.  In addition it does not depend on any software outside main,
> it is believed to be wholly unencumbered by patents, and is believed to
> have no legal encumbrances that could affect users or our ftp archive
> operators.

I think we need to say explicitly that only main is part of the Debian
distribution.  I'd also rather not add any mentions of legal vetting other
than referring to the DFSG, since this is a bit of a minefield.  How
about:

The main archive area comprises the Debian GNU/Linux 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.

and then going on to the language already there, which already requires
that all the packages comply with the DFSG.

> 2.2.2 The contrib archive area

> The contrib archive area is where fully policy compliant and DFSG free
> software is put that depends on or recommends non-free software or
> software that is otherwise unavailable within Debian.  Contrib software
> is believed to be wholly unencumbered by patents and to have no legal
> encumbrances that could affect users or our ftp archives.  However,
> contrib software usually requires using either non-free software or
> software that is otherwise not available or not policy compliant.

The contrib archive area contains supplemental packages intended to
work with the Debian GNU/Linux distribution, but which require
software outside of the distribution to either build or function.
Apart from this requirement, all software in the contrib archive area
complies with the DFSG and with the policy requirements in this
manual.

> 2.2.3 The non-free archive area

> The non-free archive area is where software that is freely
> redistributable, but not fully policy compliant (which can be as simple
> as failing the software build requirements) or not DFSG free, or is
> encumbered by patents or is affected by other legal issues that could
> affect our users or our ftp infrastructure.

The non-free archive area contains supplemental packages intended to
work with the Debian GNU/Linux distribution that do not comply with
the DFSG or have other problems that make their distribution
problematic.  They may not comply with all of the policy requirements
in this manual due to restrictions on modifications or other
limitations.

I don't think any of the above changes anything normative, so once we
reach consensus on the wording I can go ahead and apply this.

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



-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87hbig3qih@windlord.stanford.edu

Bug#89038: mime policy copying update-mime(8)

[Russ Allbery]

Ben Finney  writes:
> On Fri, Jun 06, 2008 at 10:47:11AM -0700, Russ Allbery wrote:

>> I agree with the original bug reporter that mime-policy as it stands
>> right now should be merged into Policy and cease to exist as an
>> independent document unless we're going to add more detailed
>> information to it.

> Attached is a patch that simply incorporates the useful content from
> ‘mime-policy’ into the main ‘policy’ document, and removes the
> redundant document.

Seconded.

Note, for others following this bug, that this patch just moves the
existing information and doesn't include the information from
update-mime(8) into Policy, which means that one still has to read that
man page to find out the formatting of the entry in the
/usr/lib/mime/packages directory.  (Which should really be /usr/share, but
that's another problem, since /usr/share/mime/packages is apparently being
used by something else.)  If people believe more of the information from
update-mime(8) should be included in Policy, now's the time to speak
up

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



--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87r5hj3oq0@windlord.stanford.edu

Processed: user debian-pol...@packages.debian.org, limit package to debian-policy, usertagging 89038 ...

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> user debian-pol...@packages.debian.org
Setting user to debian-pol...@packages.debian.org (was r...@debian.org).
> limit package debian-policy
Limiting to bugs with field 'package' containing at least one of 'debian-policy'
Limit currently set to 'package':'debian-policy'

> usertags 89038 = normative
Bug#89038: [mime-policy] Include update-mime behavior
Usertags were: normative proposal.
Usertags are now: normative.
> tags 89038 + patch
Bug #89038 [debian-policy] [mime-policy] Include update-mime behavior
Added tag(s) patch.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
89038: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=89038
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/handler.s.c.128293306731294.transcr...@bugs.debian.org

Bug#593909: debian-policy: Clarifications about the syntax of Debian control files.

[Bernhard R. Link]

* Russ Allbery  [100827 19:27]:
> I'm torn on that bug.  The ideal thing to do there, I think, is to say
> that lines consisting solely of spaces and tabs are a syntax error and are
> not allowed, but parsers may accept them as paragraph separators.  (Be
> conservative in what you generate and liberal in what you accept.)

I'd rather see if it encourages parsers to error out in those cases
(Fail early, fail often). If something accepts them because they cannot
propagate the error properly that is no big problem. But if too many
allow them they will get used and there will definitly be code that has
problems because there is simply no way to test all those different
cases.

Bernhard R. Link



-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20100827190148.ga3...@pcpool00.mathematik.uni-freiburg.de

Bug#594542: debian-policy: add descriptions for main, contrib, and non-free archive areas

[Russ Allbery]

CJ Fearnley  writes:

> However, I do wish that we could figure out how to write a
> minefield-avoiding third sentence for your paragraph on the main archive
> area that definitively asserts (what I believe we all know to be true)
> that Debian main is more or less a guarantee that the software therein
> is freely usable (and distributable) in the broadest sense.  That is,
> that Debian main is unreservedly usable for personal, non-profit,
> for-profit, or, in short, for any purpose.

> But I'm blanking on text that would work.

Isn't that basically what the DFSG says, though?  At least, that was the
logic that I was using.

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



-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/878w3r3lxf@windlord.stanford.edu

Bug#594542: debian-policy: add descriptions for main, contrib, and non-free archive areas

[CJ Fearnley]

Russ,

Your text accommodates almost all of my ideas while being simpler,
clearer and minefield-avoiding.  So I enthusiastically endorse it.

However, I do wish that we could figure out how to write a
minefield-avoiding third sentence for your paragraph on the main archive
area that definitively asserts (what I believe we all know to be true)
that Debian main is more or less a guarantee that the software therein is
freely usable (and distributable) in the broadest sense.  That is, that
Debian main is unreservedly usable for personal, non-profit, for-profit,
or, in short, for any purpose.

But I'm blanking on text that would work.

On Fri, Aug 27, 2010 at 10:38:14AM -0700, Russ Allbery wrote:
> CJ Fearnley  writes:
> 
> > Especially since the main, contrib, and non-free archive areas are not
> > described anywhere else (as far as I can tell), it would be helpful if
> > some descriptive text were added to explain the intent of policy.  I
> > suggest the following in the hopes that others will flesh out the
> > descriptions to be more accurate and complete than my first cut:
> 
> > 2.2.1 The main archive area
> 
> > The main archive area is where the core of the Debian GNU/Linux system
> > lives.  All of the software in main can stand alone as a fully
> > operational system without any software from contrib or non-free.  The
> > software included in main is vetted to ensure compliance with policy and
> > the DFSG.  In addition it does not depend on any software outside main,
> > it is believed to be wholly unencumbered by patents, and is believed to
> > have no legal encumbrances that could affect users or our ftp archive
> > operators.
> 
> I think we need to say explicitly that only main is part of the Debian
> distribution.  I'd also rather not add any mentions of legal vetting other
> than referring to the DFSG, since this is a bit of a minefield.  How
> about:
> 
> The main archive area comprises the Debian GNU/Linux 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.
> 
> and then going on to the language already there, which already requires
> that all the packages comply with the DFSG.
> 
> > 2.2.2 The contrib archive area
> 
> > The contrib archive area is where fully policy compliant and DFSG free
> > software is put that depends on or recommends non-free software or
> > software that is otherwise unavailable within Debian.  Contrib software
> > is believed to be wholly unencumbered by patents and to have no legal
> > encumbrances that could affect users or our ftp archives.  However,
> > contrib software usually requires using either non-free software or
> > software that is otherwise not available or not policy compliant.
> 
> The contrib archive area contains supplemental packages intended to
> work with the Debian GNU/Linux distribution, but which require
> software outside of the distribution to either build or function.
> Apart from this requirement, all software in the contrib archive area
> complies with the DFSG and with the policy requirements in this
> manual.
> 
> > 2.2.3 The non-free archive area
> 
> > The non-free archive area is where software that is freely
> > redistributable, but not fully policy compliant (which can be as simple
> > as failing the software build requirements) or not DFSG free, or is
> > encumbered by patents or is affected by other legal issues that could
> > affect our users or our ftp infrastructure.
> 
> The non-free archive area contains supplemental packages intended to
> work with the Debian GNU/Linux distribution that do not comply with
> the DFSG or have other problems that make their distribution
> problematic.  They may not comply with all of the policy requirements
> in this manual due to restrictions on modifications or other
> limitations.
> 
> I don't think any of the above changes anything normative, so once we
> reach consensus on the wording I can go ahead and apply this.
> 
> -- 
> Russ Allbery (r...@debian.org)   

-- 
We are on a spaceship; a beautiful one.  It took billions of years to develop.
We're not going to get another.  Now, how do we make this spaceship work?
  -- Buckminster Fuller

CJ Fearnley|  Explorer in Universe
c...@cjfearnley.com |  "Dare to be Naive" -- Bucky Fuller
http://www.CJFearnley.com  |  http://blog.remoteresponder.net/



-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100827190134.gj18...@linuxforce.net

Bug#594542: debian-policy: add descriptions for main, contrib, and non-free archive areas

[CJ Fearnley]

On Fri, Aug 27, 2010 at 12:17:16PM -0700, Russ Allbery wrote:
> CJ Fearnley  writes:
> 
> > However, I do wish that we could figure out how to write a
> > minefield-avoiding third sentence for your paragraph on the main archive
> > area that definitively asserts (what I believe we all know to be true)
> > that Debian main is more or less a guarantee that the software therein
> > is freely usable (and distributable) in the broadest sense.  That is,
> > that Debian main is unreservedly usable for personal, non-profit,
> > for-profit, or, in short, for any purpose.
> 
> > But I'm blanking on text that would work.
> 
> Isn't that basically what the DFSG says, though?  At least, that was the
> logic that I was using.

The DFSG defines freedom in software licenses, but doesn't provide a
statement of assurance to users.  Maybe a statement that Debian main
supports the Four Freedoms[1][2] would turn the prescriptive DFSG into
a qualitative benefits statement.

1. http://en.wikipedia.org/wiki/Four_Freedoms_(software)#Definition
2. http://www.gnu.org/philosophy/free-sw.html

-- 
We are on a spaceship; a beautiful one.  It took billions of years to develop.
We're not going to get another.  Now, how do we make this spaceship work?
  -- Buckminster Fuller

CJ Fearnley|  Explorer in Universe
c...@cjfearnley.com |  "Dare to be Naive" -- Bucky Fuller
http://www.CJFearnley.com  |  http://blog.remoteresponder.net/



-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100827220656.gk18...@linuxforce.net

Bug#594274: debian-policy: Don't track generated README documents in VCS

[Ben Finney]

Russ Allbery  writes:

> This was intentional when those files were introduced since rebuilding
> them requires Emacs, and the concern was that not everyone who worked
> on Policy would want to have Emacs installed.

Thanks for the explanation.

I think that Emacs should simply be a build dependency, as Docbook is.
Why would “I don't want Emacs installed” be any more valid than “I don't
want Docbook installed”?

The desire to not *use* Emacs is a valid one; but one does not need
Emacs to edit the README.org source.

> If that's no longer a concern, I can remove the generated files and
> build them from debian/rules by default.

(And add ‘emacs’ to ‘Build-Depends-Indep’, I assume.)

I don't know for whom it was a concern. How will we know if those
concerns are now addressed?

> In the long run, if we're standardizing on Docbook, they should also
> be converted to Docbook.

Sure, at which point Emacs would no longer be a build dependency.

-- 
 \ “I wish there was a knob on the TV to turn up the intelligence. |
  `\  There's a knob called ‘brightness’ but it doesn't work.” |
_o__) —Eugene P. Gallagher |
Ben Finney 



--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/877hjbisq1@benfinney.id.au

Re: Bug#106073: recommend to install documentation into /usr/share/doc//

[Ben Finney]

Russ Allbery  writes:

> Thank you for writing this up!

It's my pleasure.

> I'm inclined to second this, although I wonder if should is too strong
> at this point and we should instead allow for either method but
> document that using the same directory as the "parent" package is
> preferred. That would avoid the instantly buggy issue but still set up
> a transition over time.

Can you show me an example (perhaps elsewhere in Policy) that shows the
less-strong wording you have in mind?

> We'll need a Lintian tag, etc., to actually get everything moved over.

Should that be a separate bug report?

> I also agree with Bill that it might be useful to say that one should
> have a symlink or symlinks in the /usr/share/doc/package-doc directory
> pointing to the docs in the other directory (or vice versa; it doesn't
> really matter which direction the linking goes). That would also make
> the transition easier.

This might need more discussion; I didn't see a good consensus on that
part. More bug reports, or am I getting overly picky?

> > + The documentation must be installed as specified in
> > + .
>
> I think that last "must" should be a "should".

Why so? It's merely saying that another section of Policy must be
followed. If that section includes less-strong language, the “must” here
is exactly as restrictive or non-restrictive as that other section's
wording.

-- 
 \ “Teach a man to make fire, and he will be warm for a day. Set a |
  `\   man on fire, and he will be warm for the rest of his life.” |
_o__) —John A. Hrastar |
Ben Finney


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/8739tziscr@benfinney.id.au

Bug#594274: debian-policy: Don't track generated README documents in VCS

[Russ Allbery]

Ben Finney  writes:
> Russ Allbery  writes:

>> If that's no longer a concern, I can remove the generated files and
>> build them from debian/rules by default.

> (And add ‘emacs’ to ‘Build-Depends-Indep’, I assume.)

> I don't know for whom it was a concern. How will we know if those
> concerns are now addressed?

Bill, do you mind if we make Emacs a build requirement for Policy for the
*.org files that are in there right now?  I think you were the one who
expressed concerns previously about the org files.

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



--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87zkw7zn51@windlord.stanford.edu

Re: Bug#593909: debian-policy: Clarifications about the syntax of Debian control files.

[Ben Finney]

Russ Allbery  writes:

> In that case, yes, we should say that the order of paragraphs is
> significant, since indeed it always has been. Probably just by adding
> the sentence "The order of paragraphs in the control file is
> significant" to the end of the first paragraph.

The source package stanza must come first, I can see why that's
significant. But why does the order of binary package stanzas matter?

-- 
 \   “An idea isn't responsible for the people who believe in it.” |
  `\  —Donald Robert Perry Marquis |
_o__)  |
Ben Finney


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87y6brhdnx@benfinney.id.au

Bug#593909: debian-policy: Clarifications about the syntax of Debian control files.

[Russ Allbery]

Ben Finney  writes:
> Russ Allbery  writes:

>> In that case, yes, we should say that the order of paragraphs is
>> significant, since indeed it always has been. Probably just by adding
>> the sentence "The order of paragraphs in the control file is
>> significant" to the end of the first paragraph.

> The source package stanza must come first, I can see why that's
> significant. But why does the order of binary package stanzas matter?

debhelper(7):

   Note that if a package is the first (or only) binary package listed
   in debian/control, debhelper will use debian/foo if no
   debian/package.foo file can be found.

Also, dh_listpackages returns them in control-file order and some source
packages do rely on this.  CDBS-based packages, last time I touched CDBS,
required listing shared library packages before binary packages that used
them in order for dh_shlibdeps to produce the correct results due to how
the packages were constructed (otherwise, dh_makeshlibs for the shared
library package wouldn't have run before dh_shlibdeps for the binary
package).  I've seen other examples.

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



-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87mxs7zm2l@windlord.stanford.edu

Bug#106073: recommend to install documentation into /usr/share/doc//

[Andrew McMillan]

On Fri, 2010-08-27 at 10:16 -0700, Russ Allbery wrote:
> Andrew McMillan  writes:
> 
> > My personal preference would be to encourage -doc packages to install
> > their files into /usr/share/doc//docs - including their
> > internal administrivia.
> 
> That would break Lintian, apt-listchanges, probably the DAK processing
> scripts, and anything else that looks at copyright and changelog in binary
> packages.  I don't think it's worth it to make that change.
> 
> > While this is not current practice, I'm not convinced that current
> > practice has evolved into what was suggested in 2003 either.
> 
> Right now, I'm seeing a real mix of behavior, with some packages
> installing all the documentation into the -doc package's /usr/share/doc
> (probably in part because that's easier) and others installing it into the
> parent package, some with symlinks and some without.  As a result, right
> now one cannot easily find the documentation in any standardized place.
> 
> > I also remember as a user hunting for these documents the first time or
> > two when I had installed the -doc package and it slowly dawning on me
> > that they weren't anywhere in /usr/share/doc/, and I think that
> > breaks the principal of least surprise, for everyone except long-time,
> > hard-core Debianista.
> 
> Yeah, that's what Ben's writeup would fix, and I agree that's worth
> fixing.
> 
> > Those points are justifications for both proposals, of course, and I
> > guess that one reason for retaining the administrivia
> > in /usr/share/doc/-doc might be that there are tools that
> > expect to find it there.  Is that the case?
> 
> Yup.
> 
> > I don't think I ever do more than refer to them by hand, and either
> > proposed change can probably be codified in some small number of
> > scripts.
> 
> I don't think the change proposed here requires changing any scripts,
> although it will require changing a bunch of packages (and a change to
> debhelper to make it easier to install docs into the right place would be
> useful).

In that case I support changing it the way Ben proposes.  I can
certainly see the value of standardising it, and doing it this way
definitely improves the situation.

Cheers,
Andrew.

-- 

andrew (AT) morphoss (DOT) com+64(272)DEBIAN
   I'll burn my books.
-- Christopher Marlowe




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

Dpkg triggers for update-mime? Re: Bug#89038: mime policy copying update-mime(8)

[Charles Plessy]

Le Wed, Aug 25, 2010 at 02:41:46PM +1000, Ben Finney a écrit :
> +
> + 
> +   Packages containing such programs must register them
> +   with update-mime as documented in  +   name="update-mime" section="8">. They should not depend
> +   on, recommend, or suggest mime-support. Instead,
> +   they should just put something like the following in the
> +   postinst and postrm scripts:
> +
> +
> +  if [ -x /usr/sbin/update-mime ]; then
> +  update-mime
> +  fi
> +   

Thanks Ben for your patch.

By the way, wouldn't mime-support be a good candidate for declaring dpkg
triggers?

Have a nice day,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100828001602.ga22...@merveille.plessy.net

Bug#196367: debian-policy: clarify what to do about priority mismatches

[Ben Finney]

Howdy all,

(FTP masters: we are asking for your attention to this bug report,
but is *not* urgent. We are aware the Squeeze release is active, and
any work to do with that has higher importance than this bug report.)


This bug report appears to need further discussion. To summarise:

Policy's current wording (in §2.5 and §5.6.6) strongly implies that an
erroneous Priority value is a Policy-violating bug in the package with
that priority. There is consensus that should not the case, especially
now that ftpmaster maintains Priority values in an override file; so
the Policy wording needs to be improved.


There are open questions:

Does the ftpmaster team find it at all useful to have bug reports
against the packages with incorrect priorities?

For incorrect priority of a package, is there an appropriate bug
report target other than the package itself?

Is the canonical location of the Priority value now the override file
maintained by ftpmaster?

If so, Policy's current description of the Priority field in packages
is outdated and very misleading; what should Policy say about the
Priority field in the packages themselves?

(dependent on the answers to the above) What should Policy say about
filing bugs against packages with erroneous Priority values? What
should Policy say about the ftpmaster override file?

-- 
 \   “Prediction is very difficult, especially of the future.” |
  `\   —Niels Bohr |
_o__)  |
Ben Finney 


signature.asc
Description: Digital signature

Bug#196367: debian-policy: clarify what to do about priority mismatches

[Ben Finney]

package debian-policy
user debian-pol...@packages.debian.org
usertags 196367 + discussion
tags 196367 + patch
thanks

Ben Finney  writes:

> Policy's current wording (in §2.5 and §5.6.6) strongly implies that an
> erroneous Priority value is a Policy-violating bug in the package with
> that priority. There is consensus that should not the case, especially
> now that ftpmaster maintains Priority values in an override file; so
> the Policy wording needs to be improved.
>
>
> There are open questions:

Meanwhile, here is my take on a patch to address this bug. It makes
assumptions about some of the answers to the open questions, so it is
likely wrong or incomplete.

=== modified file 'policy.sgml'
--- policy.sgml	2010-08-18 20:55:34 +
+++ policy.sgml	2010-08-28 00:43:43 +
@@ -783,9 +783,16 @@
 
 	
 	  Packages must not depend on packages with lower priority
-	  values (excluding build-time dependencies).  In order to
+	  values (excluding build-time dependencies). In order to
 	  ensure this, the priorities of one or more packages may need
-	  to be adjusted.
+	  to be adjusted.
+	The Priority field of an existing Debian package does not
+	determine the priority of that package;
+	see . For this reason, the package
+	maintainer cannot fix this directly, and it is not
+	recommended to file bugs against packages whose source
+	declares an incorrect Priority field.
+	  
 	
   
 
@@ -2842,6 +2849,13 @@
 	It also gives the default for the same field in the binary
 	packages.
 	  
+
+	  
+	Once a package is in Debian, this field no longer
+	determines the priority of the package in the archive.
+	Instead, the Debian ftpmaster team maintains priority
+	values in the “override file”.
+	  
 	
 
 	


-- 
 \   “I do not believe in forgiveness as it is preached by the |
  `\church. We do not need the forgiveness of God, but of each |
_o__)other and of ourselves.” —Robert G. Ingersoll |
Ben Finney 


pgpeT4WbZNV0T.pgp
Description: PGP signature

Bug#594542: debian-policy: add descriptions for main, contrib, and non-free archive areas

[Charles Plessy]

Le Fri, Aug 27, 2010 at 10:38:14AM -0700, Russ Allbery a écrit :
> 
> I think we need to say explicitly that only main is part of the Debian
> distribution.  I'd also rather not add any mentions of legal vetting other
> than referring to the DFSG, since this is a bit of a minefield.  How
> about:
> 
> The main archive area comprises the Debian GNU/Linux 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.

Hi Russ,

Actually, with the release of GNU/kFreeBSD variants for Squeeze, this paragraph
is not totally accurate.  How about ‘Debian operating system’ ?  The other
advantage I see is that it avoids the paradox that the non-free packages that
are distributed by the Debian project are not part of the Debian
‘distribution’.

On the other hand, perhaps it is better to postpone this discussion until the
Squeeze release, and use the generic name that will be in the title of the
press release.


Have a nice week-end,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan



--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100828005746.gb22...@merveille.plessy.net

Processed: Re: Bug#196367: debian-policy: clarify what to do about priority mismatches

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> package debian-policy
Limiting to bugs with field 'package' containing at least one of 'debian-policy'
Limit currently set to 'package':'debian-policy'

> user debian-pol...@packages.debian.org
Setting user to debian-pol...@packages.debian.org (was 
ben+deb...@benfinney.id.au).
> usertags 196367 + discussion
Bug#196367: Clarify Policy on priority inversion in dependencies
Usertags were: normative proposal.
Usertags are now: normative proposal discussion.
> tags 196367 + patch
Bug #196367 [debian-policy] Clarify Policy on priority inversion in dependencies
Added tag(s) patch.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
196367: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=196367
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/handler.s.c.12829567719106.transcr...@bugs.debian.org

Bug#594542: debian-policy: add descriptions for main, contrib, and non-free archive areas

[Russ Allbery]

Charles Plessy  writes:

> Actually, with the release of GNU/kFreeBSD variants for Squeeze, this
> paragraph is not totally accurate.

That's a very good point.

> How about ‘Debian operating system’ ?  The other advantage I see is that
> it avoids the paradox that the non-free packages that are distributed by
> the Debian project are not part of the Debian ‘distribution’.

I personally prefer Debian distribution and don't find that paradoxical,
but I don't feel very strongly about it.

> On the other hand, perhaps it is better to postpone this discussion
> until the Squeeze release, and use the generic name that will be in the
> title of the press release.

Nah, I think this is a simple enough report that I'd rather resolve it
quickly while we're talking about it.

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



--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87vd6vo7tm@windlord.stanford.edu

Bug#196367: debian-policy: clarify what to do about priority mismatches

[Russ Allbery]

tags 196367 - patch
thanks

patch means that you're actively asking for seconds, which it sounds from
what you write below that you're not yet.

Ben Finney  writes:

> package debian-policy
> user debian-pol...@packages.debian.org
> usertags 196367 + discussion
> tags 196367 + patch
> thanks

Due to a bug in how I have the user categories set up, right now
discussion overrides patch (when it should probably be the other way
around).  I try to make sure that only one of the state tags is applied to
a bug at any given time, just to make sure that there isn't any confusion.

> Meanwhile, here is my take on a patch to address this bug. It makes
> assumptions about some of the answers to the open questions, so it is
> likely wrong or incomplete.

This seems fine to me, although it would be nice to get an ftpmaster
response to your query before applying it.  It may be that they want all
priority changes vetted by the maintainer first.  I'm not sure.

> === modified file 'policy.sgml'
> --- policy.sgml   2010-08-18 20:55:34 +
> +++ policy.sgml   2010-08-28 00:43:43 +
> @@ -783,9 +783,16 @@
>  
>   
> Packages must not depend on packages with lower priority
> -   values (excluding build-time dependencies).  In order to
> +   values (excluding build-time dependencies). In order to
> ensure this, the priorities of one or more packages may need
> -   to be adjusted.
> +   to be adjusted.
> + The Priority field of an existing Debian package does not
> + determine the priority of that package;
> + see . For this reason, the package
> + maintainer cannot fix this directly, and it is not
> + recommended to file bugs against packages whose source
> + declares an incorrect Priority field.
> +   
>   
>
>  
> @@ -2842,6 +2849,13 @@
>   It also gives the default for the same field in the binary
>   packages.
> 
> +
> +   
> + Once a package is in Debian, this field no longer
> + determines the priority of the package in the archive.
> + Instead, the Debian ftpmaster team maintains priority
> + values in the “override file”.
> +   
>   
>  
>   

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



--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87r5hjo7mq@windlord.stanford.edu

Processed: Re: Bug#196367: debian-policy: clarify what to do about priority mismatches

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> tags 196367 - patch
Bug #196367 [debian-policy] Clarify Policy on priority inversion in dependencies
Removed tag(s) patch.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
196367: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=196367
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/handler.s.c.128295843717082.transcr...@bugs.debian.org

Re: Bug#594542: debian-policy: add descriptions for main, contrib, and non-free archive areas

[Ben Finney]

Russ Allbery  writes:

> Charles Plessy  writes:
> > How about ‘Debian operating system’ ? The other advantage I see is
> > that it avoids the paradox that the non-free packages that are
> > distributed by the Debian project are not part of the Debian
> > ‘distribution’.
>
> I personally prefer Debian distribution and don't find that
> paradoxical, but I don't feel very strongly about it.

For another data point, I have the opposite preference to Russ. I refer
to the “Debian operating system”, in part because of the confusion over
“distribution”.

Like Russ, I'm not going to get upset if that preference isn't followed
by others. In cases like this, though, “Debian operating system” would
be clearer.

-- 
 \ Lucifer: “Just sign the Contract, sir, and the Piano is yours.” |
  `\ Ray: “Sheesh! This is long! Mind if I sign it now and read it |
_o__)later?” —http://www.achewood.com/ |
Ben Finney


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87lj7rh451@benfinney.id.au

Bug#594542: debian-policy: add descriptions for main, contrib, and non-free archive areas

[Russ Allbery]

Ben Finney  writes:

> For another data point, I have the opposite preference to Russ. I refer
> to the “Debian operating system”, in part because of the confusion over
> “distribution”.

> Like Russ, I'm not going to get upset if that preference isn't followed
> by others. In cases like this, though, “Debian operating system” would
> be clearer.

I think it's because I've been doing this sort of thing for a long time,
but to me an "operating system" is only a tiny, tiny fraction of the
software that we distribute in Debian.  Things like bioperl or atlas or
openoffice.org or iceweasel are, to me, obviously not part of an
"operating system."  They're applications or tools, which sit on top of
the foundation that's created by the operating system.

To me, "operating system" is roughly what's Priority: required; all the
other stuff is something else.

But this probably just dates me more than forms a cogent argument.  :)

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



--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87k4nbscdt@windlord.stanford.edu

Bug#594542: debian-policy: add descriptions for main, contrib, and non-free archive areas

[Andrew McMillan]

On Fri, 2010-08-27 at 18:06 -0400, CJ Fearnley wrote:
> On Fri, Aug 27, 2010 at 12:17:16PM -0700, Russ Allbery wrote:
> > CJ Fearnley  writes:
> > 
> > > However, I do wish that we could figure out how to write a
> > > minefield-avoiding third sentence for your paragraph on the main archive
> > > area that definitively asserts (what I believe we all know to be true)
> > > that Debian main is more or less a guarantee that the software therein
> > > is freely usable (and distributable) in the broadest sense.  That is,
> > > that Debian main is unreservedly usable for personal, non-profit,
> > > for-profit, or, in short, for any purpose.
> > 
> > > But I'm blanking on text that would work.
> > 
> > Isn't that basically what the DFSG says, though?  At least, that was the
> > logic that I was using.
> 
> The DFSG defines freedom in software licenses, but doesn't provide a
> statement of assurance to users.  Maybe a statement that Debian main
> supports the Four Freedoms[1][2] would turn the prescriptive DFSG into
> a qualitative benefits statement.

Hi,

I think that you're treading on thin ground pushing for that.  The DFSG
is a defining document in Debian, so if you want to narrow or broaden
that coverage you should be doing so by promoting changes to that
document - not to policy.

Personally I'm happy with the freedoms described by the DFSG as it
stands at present, but if you believe it is flawed you should argue
those flaws in the wider arena of Debian via a GR or such.

The clarifications Russ suggested definitely do seem worth including,
and I would say it is especially because they refer out to that defining
document that gives them their strength in policy.  If they were to
place additional constraints on what software was acceptable in main it
would make policy more confusing, not less, and would undermine the DFSG
as a decision-making tool.

Regards,
Andrew McMillan.
-- 

andrew (AT) morphoss (DOT) com+64(272)DEBIAN
   A tall, dark stranger will have more fun than you.




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

Bug#594542: debian-policy: add descriptions for main, contrib, and non-free archive areas

[Russ Allbery]

Andrew McMillan  writes:
> On Fri, 2010-08-27 at 18:06 -0400, CJ Fearnley wrote:

>> The DFSG defines freedom in software licenses, but doesn't provide a
>> statement of assurance to users.  Maybe a statement that Debian main
>> supports the Four Freedoms[1][2] would turn the prescriptive DFSG into
>> a qualitative benefits statement.

> I think that you're treading on thin ground pushing for that.  The DFSG
> is a defining document in Debian, so if you want to narrow or broaden
> that coverage you should be doing so by promoting changes to that
> document - not to policy.

> Personally I'm happy with the freedoms described by the DFSG as it
> stands at present, but if you believe it is flawed you should argue
> those flaws in the wider arena of Debian via a GR or such.

I don't think CJ is advocating changing the DFSG, but rather is concerned
that the way the DFSG is worded may not make it clear to people what the
motivation is and what the implications are for users.  In other words, a
rephrasing or preamble, not any sort of normative modification, that says
"this means you can use the software for absolutely anything you want."

I can see that point, although I'm not sure that it makes that much
difference for Policy, since Policy is largely aimed at people who are
reasonably familiar with Debian and are looking for technical guidance.

I would tend to point people at http://www.debian.org/intro/free or some
similar sort of place to explain the motivation and background for what
Debian means by free.

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



-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/871v9js6zp@windlord.stanford.edu

Bug#594542: debian-policy: add descriptions for main, contrib, and non-free archive areas

[Guillem Jover]

Hi!

On Fri, 2010-08-27 at 18:16:21 -0700, Russ Allbery wrote:
> Charles Plessy  writes:
> > Actually, with the release of GNU/kFreeBSD variants for Squeeze, this
> > paragraph is not totally accurate.
> 
> That's a very good point.

Yeah, I was about to comment on just that but then I saw Charles
mail. (It could also be argued that GNU/Hurd is also part of the
distribution, even though it has never been released.)

> > How about ‘Debian operating system’ ?  The other advantage I see is that
> > it avoids the paradox that the non-free packages that are distributed by
> > the Debian project are not part of the Debian ‘distribution’.
> 
> I personally prefer Debian distribution and don't find that paradoxical,
> but I don't feel very strongly about it.

FWIW me too.

> > On the other hand, perhaps it is better to postpone this discussion
> > until the Squeeze release, and use the generic name that will be in the
> > title of the press release.
> 
> Nah, I think this is a simple enough report that I'd rather resolve it
> quickly while we're talking about it.

I also checked for other instances in the current policy package and
I'm filing a new bug report with a patch for that.

regards,
guillem



--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100828063518.ga8...@gaara.hadrons.org

Bug#594656: debian-policy: Refer generically to the Debian distribution

[Guillem Jover]

Source: debian-policy
Source-Version: 3.9.1.0
Severity: wishlist
Tags: patch

Hi!

The attached patch fixes all relevant references to the Debian
distribution (or system) by removing references to the particular
GNU/Linux system.

I've left two references to Debian GNU/Linux as they are historical.

regards,
guillem
>From 4d13fa337774fc540b87e4e607bdb04e7ee94a83 Mon Sep 17 00:00:00 2001
From: Guillem Jover 
Date: Sat, 28 Aug 2010 08:11:28 +0200
Subject: [PATCH] Refer generically to Debian instead of the GNU/Linux instance

---
 debian-menu-policy.desc |2 +-
 debian-mime-policy.desc |2 +-
 debian-perl-policy.desc |2 +-
 debian-policy.desc  |2 +-
 debian/copyright|2 +-
 menu-policy.sgml|4 ++--
 mime-policy.sgml|6 +++---
 perl-policy.sgml|4 ++--
 policy.sgml |   23 ++-
 9 files changed, 22 insertions(+), 25 deletions(-)

diff --git a/debian-menu-policy.desc b/debian-menu-policy.desc
index d3eb5c2..9757253 100644
--- a/debian-menu-policy.desc
+++ b/debian-menu-policy.desc
@@ -2,7 +2,7 @@ Document: debian-menu-policy
 Title: Debian Menu Policy Manual
 Author: The Debian Policy Mailing list
 Abstract: This manual describes the policy requirements for the Menu
- system in the Debian GNU/Linux distribution, describing the
+ system in the Debian distribution, describing the
  hierarchical structure of the menu sections.
 Section: Debian
 
diff --git a/debian-mime-policy.desc b/debian-mime-policy.desc
index 92c4e4d..512e483 100644
--- a/debian-mime-policy.desc
+++ b/debian-mime-policy.desc
@@ -2,7 +2,7 @@ Document: debian-mime-policy
 Title: Debian MIME Policy Manual
 Author: The Debian Policy Mailing list
 Abstract: This manual describes the policy requirements for the MIME
- system in the Debian GNU/Linux distribution, describing the rules
+ system in the Debian distribution, describing the rules
  regulating the registration of programs that can handle MIME
  content.
 Section: Debian
diff --git a/debian-perl-policy.desc b/debian-perl-policy.desc
index 931e937..cb6337c 100644
--- a/debian-perl-policy.desc
+++ b/debian-perl-policy.desc
@@ -2,7 +2,7 @@ Document: debian-perl-policy
 Title: Debian Perl Policy Manual
 Author: The Debian Policy Mailing list
 Abstract: This manual describes the policy requirements for the Perl
- system in the Debian GNU/Linux distribution, describing the rules
+ system in the Debian distribution, describing the rules
  regulating the building and installation of packages providing and
  using Perl and Perl modules.
 Section: Debian
diff --git a/debian-policy.desc b/debian-policy.desc
index a5e22ac..745538e 100644
--- a/debian-policy.desc
+++ b/debian-policy.desc
@@ -2,7 +2,7 @@ Document: debian-policy
 Title: Debian Policy Manual
 Author: The Debian Policy Mailing list
 Abstract: This manual describes the policy requirements for the Debian
- GNU/Linux distribution. This includes the structure and contents of
+ distribution. This includes the structure and contents of
  the Debian archive, several design issues of the operating system, as
  well as technical requirements that each package must satisfy to be
  included in the distribution.
diff --git a/debian/copyright b/debian/copyright
index 2257707..b521cf6 100644
--- a/debian/copyright
+++ b/debian/copyright
@@ -24,7 +24,7 @@ fitness for a particular purpose. See the GNU General Public License
 for more details.
 
 You should have received a copy of the GNU General Public License with
-your Debian GNU/Linux system, in /usr/share/common-licenses/GPL-2, or
+your Debian system, in /usr/share/common-licenses/GPL-2, or
 with the dpkg source package as the file COPYING. If not, write to the
 Free Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
 MA 02110-1301 USA
diff --git a/menu-policy.sgml b/menu-policy.sgml
index 1ad2fab..c919740 100644
--- a/menu-policy.sgml
+++ b/menu-policy.sgml
@@ -31,7 +31,7 @@
 
   
 	This manual describes the policy requirements for the Menu
-	system used in the Debian GNU/Linux distribution. This
+	system used in the Debian distribution. This
 	document is part of the policy package for Debian.
   
 
@@ -54,7 +54,7 @@
 	
 	
 	  A copy of the GNU General Public License is available as
-	  /usr/doc/copyright/GPL in the Debian GNU/Linux
+	  /usr/doc/copyright/GPL in the Debian
 	  distribution or on the World Wide Web at 
 	  http://www.gnu.org/copyleft/gpl.html";
 	  name="The GNU General Public Licence">. You can also obtain it by writing to the
diff --git a/mime-policy.sgml b/mime-policy.sgml
index 38db3ef..e05ee4a 100644
--- a/mime-policy.sgml
+++ b/mime-policy.sgml
@@ -5,7 +5,7 @@
 ]>