On ma, 2010-08-23 at 14:50 +1200, Lars Wirzenius wrote:
> On su, 2010-08-22 at 15:24 -0700, Russ Allbery wrote:
> > It's... okay. It's a little strange, but I don't think it would be
> > confusing since it is a summary of the license text in a machine-readable
> > format, in essence.
>
> ACK, you
Charles Plessy writes:
> I have mixed feelings about adding a extra level of complexity and
> introduce a syntax for lists. I think that apart from the Files field,
> the DEP could use mostly free-form values in the fields.
> In particular for the Copyright field, I am of the opinion that it
> s
Lars Wirzenius writes:
> On la, 2010-08-21 at 01:58 -0700, Russ Allbery wrote:
>> I was assuming that's how we'd get to a 1.1 version. I haven't read
>> DEP-0 recently, though, so I guess I have a poor grasp of how this is
>> supposed to work. I'll go review it. If we pick up the files in
>> d
On su, 2010-08-22 at 15:24 -0700, Russ Allbery wrote:
> It's... okay. It's a little strange, but I don't think it would be
> confusing since it is a summary of the license text in a machine-readable
> format, in essence.
ACK, you and Ben have assured me that it is acceptable, and I've changed
the
Lars Wirzenius writes:
> On su, 2010-08-22 at 16:12 +0900, Charles Plessy wrote:
> > If the extended description finally requires double space for
> > verbatim display, then how abould calling the ‘special first line’
> > synopsis, to be closer to the vocabulary used in the specification
> > of t
Lars Wirzenius writes:
> On su, 2010-08-22 at 16:12 +0900, Charles Plessy wrote:
>> If the extended description finally requires double space for verbatim
>> display, then how abould calling the ‘special first line’ synopsis, to
>> be closer to the vocabulary used in the specification of the
>> D
I've attached the current diff for the general file syntax changes.
=== modified file 'dep5.mdwn'
--- dep5.mdwn 2010-08-21 09:05:12 +
+++ dep5.mdwn 2010-08-22 22:08:51 +
@@ -76,7 +76,7 @@
* Single-line values.
* White space separated lists.
* Line based lists.
-* Free-form text formatted
On su, 2010-08-22 at 16:12 +0900, Charles Plessy wrote:
> I also feel a contradiction to call ‘free-form’ some text that is formatted
> according to some markup rules, even if they are simple. I propose to replace
> instances like:
>
> Free-form text formatted like package long descriptions
>
>
On la, 2010-08-21 at 22:30 -0700, Manoj Srivastava wrote:
> Can't we just "fold" long copyright header fields similarly?
The issue is that one Copyright field (or header) will contain many
copyright statements, and if we want to automatically parse those, we
need a way to see where a new o
Le Sat, Aug 21, 2010 at 09:09:28PM +1200, Lars Wirzenius a écrit :
>
> +There are four kinds values for fields. Each field specifies which
> +kind is allowed.
> +i
> +* Single-line values.
> +* White space separated lists.
> +* Line based lists.
> +* Free-form text formatted like package long des
On Sat, Aug 21 2010, Russ Allbery wrote:
> Ben Finney writes:
>> Lars Wirzenius writes:
>
>>> * Have one copyright statement per Copyright field, and have multiple
>>> instances of the field.
>
>> This is my preference, and what I've been doing in my packages.
>
> Unfortunately, this creates rea
On Sun, Aug 22, 2010 at 11:36:54AM +1200, Lars Wirzenius wrote:
> On su, 2010-08-22 at 08:00 +1000, Ben Finney wrote:
> > Could we take advantage of the natural “©” marker to indicate each
> > copyright statement?
> That's an interesting idea, but would people in general find it easy or
> difficul
On Sun, Aug 22, 2010 at 11:36:54AM +1200, Lars Wirzenius wrote:
> On su, 2010-08-22 at 08:00 +1000, Ben Finney wrote:
> > Could we take advantage of the natural “©” marker to indicate each
> > copyright statement?
>
> That's an interesting idea, but would people in general find it easy or
> diffic
On su, 2010-08-22 at 08:00 +1000, Ben Finney wrote:
> Could we take advantage of the natural “©” marker to indicate each
> copyright statement?
That's an interesting idea, but would people in general find it easy or
difficult to write that character? (I'd have to copy-paste it, for
instance, since
Russ Allbery writes:
> Ben Finney writes:
> > Lars Wirzenius writes:
>
> >> * Have one copyright statement per Copyright field, and have multiple
> >> instances of the field.
>
> > This is my preference, and what I've been doing in my packages.
>
> Unfortunately, this creates real challenges fo
On la, 2010-08-21 at 08:32 -0400, Stephen Leake wrote:
> Lars Wirzenius writes:
>
> > Files has a list
> > of values (currently comma-separated, but I propose to make it
> > white-space separated),
>
> File names can have spaces. Not common, but possible. I guess such file
> names would need to
Ben Finney writes:
> Lars Wirzenius writes:
>> * Have one copyright statement per Copyright field, and have multiple
>> instances of the field.
> This is my preference, and what I've been doing in my packages.
Unfortunately, this creates real challenges for parsers. I've written a
few RFC 532
Lars Wirzenius writes:
> On la, 2010-08-21 at 02:15 -0700, Russ Allbery wrote:
> > What happens when the copyright statement is longer than a line?
[…]
> Good point. I see at least thw following possible solutions:
[…]
> * Have one copyright statement per Copyright field, and have multiple
> in
Lars Wirzenius writes:
> Files has a list
> of values (currently comma-separated, but I propose to make it
> white-space separated),
File names can have spaces. Not common, but possible. I guess such file
names would need to be quoted?
--
-- Stephe
--
To UNSUBSCRIBE, email to debian-projec
On la, 2010-08-21 at 02:15 -0700, Russ Allbery wrote:
> What happens when the copyright statement is longer than a line? I have a
> bunch of those, such as:
Good point. I see at least thw following possible solutions:
* Keep one line per copyright statement, but make the lines be long.
(This is
On la, 2010-08-21 at 01:58 -0700, Russ Allbery wrote:
> > How would that tie in with updating it via the normal policy process? I
> > thought we'd keep the file in the debian-policy package for future
> > updates.
>
> I was assuming that's how we'd get to a 1.1 version. I haven't read DEP-0
> rec
Lars Wirzenius writes:
> While wording this, I realized that we have more cases: Files has a list
> of values (currently comma-separated, but I propose to make it
> white-space separated), and Copyright and maybe other fields have a list
> of values one per line. I took the liberty of taking this
On la, 2010-08-21 at 20:32 +1200, Lars Wirzenius wrote:
> I'm OK with saying that multiline fields should use the Description
> markup, especially noting Charles's point about only using the long
> description part, when appropriate. This simplifies things quite a lot.
> I'll word a concrete patch
Lars Wirzenius writes:
> On pe, 2010-08-20 at 17:05 -0700, Russ Allbery wrote:
>> I think a better approach would be to, once the document has settled
>> down, publish it with a version number and give that version of the
>> document a permanent URL. So, for instance, we would publish DEP-5 1.0
On pe, 2010-08-20 at 17:05 -0700, Russ Allbery wrote:
> I think a better approach would be to, once the document has settled down,
> publish it with a version number and give that version of the document a
> permanent URL. So, for instance, we would publish DEP-5 1.0 and give it a
> URL something
Charles Plessy writes:
> I have another comment on details of the DEP's syntax, about the order
> of paragraphs. Policy's §5.1 does not specify that the order or
> paragraphs is important, while this is a crucial information in
> DEP-5. If this is not an omission in §5.1, I recommend that this
>
Le Sat, Aug 21, 2010 at 02:30:40AM +0200, gregor herrmann a écrit :
> On Fri, 20 Aug 2010 17:05:23 -0700, Russ Allbery wrote:
>
> > That also lets the rule with License be consistent with the rule for other
> > fields, by requiring two leading spaces for any literal text. It also
> > means that w
On Fri, 20 Aug 2010 17:05:23 -0700, Russ Allbery wrote:
> That also lets the rule with License be consistent with the rule for other
> fields, by requiring two leading spaces for any literal text. It also
> means that we would be using essentially the same formatting conventions
> as Description
Lars Wirzenius writes:
> * We refer to Policy 5.1 by section number, section title, and URL. I
> don't think the policy version is necessary: if they make incompatible
> changes, then all Debian control files will potentially break, and DEP-5
> copyright files are no exception. Including the 5.1
On Wed, 18 Aug 2010 09:29:33 +1200, Lars Wirzenius wrote:
> For simplicity, I will introduce a new term, "desc-escape". This refers
> to the escaping of content similar to the way Description does it in
> debian/control: each line is prefixed with a space, except empty lines
> are replaced with a
On Wed, 18 Aug 2010, Lars Wirzenius wrote:
> If the e-mail is just a clarification to the license and does not
> modify it, then I guess License is not the right place. Rather than
> munge it into Comment, I guess we need a new field. However, how
> often do these things happen? If it is very rarel
On Tue, Aug 17, 2010 at 06:24:39PM -0700, Russ Allbery wrote:
> I wonder if we should have some terminator for the machine-readable
> portion of debian/copyright, below which is free-form supporting material
That would be the simplest way, a 'stop reading here' line for the
parsers. That way anyth
On ti, 2010-08-17 at 18:24 -0700, Russ Allbery wrote:
> Those exchanges aren't the actual license or copyright information, which
> can still be stated in a structured form. They're usually just defenses
> of why thet claimed license information is what it is (when it may, for
> example, contradic
Charles Plessy writes:
> Le Wed, Aug 18, 2010 at 09:29:33AM +1200, Lars Wirzenius a écrit :
>> For Disclaimer, and Comment if we add that, it might be helpful to have
>> empty lines, but word-wrapping is definitely needed. Newlines are not
>> significant.
> some debian/copyright files contain ex
Le Wed, Aug 18, 2010 at 09:29:33AM +1200, Lars Wirzenius a écrit :
>
> For Disclaimer, and Comment if we add that, it might be helpful to have
> empty lines, but word-wrapping is definitely needed. Newlines are not
> significant.
Hi Lars,
some debian/copyright files contain extracts of correspon
There would seem to be at least a rough consensus that DEP-5 should
follow Policy 5.1 on control file syntax. The open question how to
specify that: it is my understanding that most people favor just
referring to the relevant Policy section and not duplicate things in
DEP-5, but since that is also
36 matches
Mail list logo
