Bug#1020241: debian-policy: copyright-format: Formatting improvements/changes
Guillem Jover <guillem@debian.org> writes:
> I think Disclaimer and Comment do not seem as problematic because they
> tend to contain descriptive prose. For Source it's true that it's weird
> as it seems to indeed want to have two different semantics depending on
> the content, and considering the current deb822 format, perhaps having
> used two different field names might have been better as you alluded
> with your YAML example, say Source-Urls (line-based list), and
> Source-Comment (formatted text). Such split still seems feasible and
> backwards compatible right now though.
Yes, good point.
> Just to try to clarify to make sure we are on the same page (if we are,
> sorry for the obvious!). What I find confusing is that the semantics of
> the field imply different line-wrapping semantics depending on leading
> spaces, and because there's no synopsis, the first line is supposed to
> act just like the rest, but if spaces are ignored, then how do you
> select either of the line-wrapping behaviors for the first line? Also
> because adding such spaces after the colon look like typographic errors
> to me somehow.
Ah, I see what you're getting at. I was distinguishing between spaces on
the first line and spaces on subsequent lines and assuming that if you
wanted to mark the first line as verbatim you would have to have a newline
first. Now that you point it out, it's clear that my brain has a fairly
complicated assumed semantic model here that isn't at all clear from the
description of the field and may not even be the right thing to do.
> So I think what seems most confusing to me is that for formatted-text
> fields with no synopsis, the first line is being used at all, because
> that messes with the intuition on how the Description field operates.
Yes, this makes sense. Maybe we should encourage people to not use the
first line? (Prohibiting it is presumably too much of a compatibility
break to be worth it.)
> I was thinking that perhaps an easy way out, might be to say that if the
> field contains an empty first line (nothing after the colon), then it's
> line based, otherwise it's considered formatted text. Which makes things
> more complex (perhaps "only" for a transition period), but might be
> considered backwards compat?
This sounded promising but unfortunately I think Wouter identified the
issue, which is that if we're defining extra leading whitespace as
indicating a continuation line (which is a somewhat natural thing to do in
a format based on RFC 822 header fields), this changes the semantics of
any existing Copyright fields that happen to have skipped the first line
but are using extra indentation to indicate verbatim lines.
I think I'm talking myself into introducing a new Copyright-Lines header
as the best theoretical fix, although that will be quite annoying for
Lintian and any other tool that currently parses the file, since any file
in the new format is going to look entirely invalid.
I knew the backward compatibility issues were going to be a whole can of
worms.
--
Russ Allbery (rra@debian.org) <https://www.eyrie.org/~eagle/>
Reply to: