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
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 '
"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-pa
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
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
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 copy
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
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
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
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
>> informat
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 '
* 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 libe
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 the
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 as
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 tr
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 dependenc
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. Tha
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 ar
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 stan
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
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, prob
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. I
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 cur
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 priorit
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:
>
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 (wa
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 di
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 t
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/bug
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 Deb
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, thou
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
> > > a
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
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
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.
35 matches
Mail list logo
