Guillem Jover <guil...@debian.org> writes:
> Oh! I've completely missed this all this time, I think because that
> feels very weird given that it has no synopsis and the text is added
> already on the first line on the spec. :/
Other formatted fields with the same semantics are Source, Disclaimer, and
Comment. I don't think there are any fields in debian control files with
those semantics (Description is the only formatted field and it has a
synopsis), but there are several of them in copyright files.
Source is another ongoing minor problem, since it's *usually* a URL but is
not required to be one, and sometimes a textual description of the source
is needed. Here too, a structured format would have been nicer, so that
you could have something like:
source:
urls:
- https://example.com/foo
- https://example.org/foo
comment: >-
The foo-rewrite script was originally posted to comp.unix.sources in
1992 but otherwise has no source other than the Debian package.
Ah well.
> Right, the problem I see is that applying this formatting to a field
> that has no special treatment for the first line just after the field
> name seems very unintuitive, because the first line does not contain an
> additional prefixing space, or if it does no one is adding it!
> It feels very weird to me that all these would be equivalent:
> Copyright: Something long that might trigger some wrapping behavior
> Other thing very long that might not be clear behaves as the above
> More
> and
> Copyright: Something long that might trigger some wrapping behavior
> Other thing very long that might not be clear behaves as the above
> More
> and
> Copyright:
> Something long that might trigger some wrapping behavior
> Other thing very long that might not be clear behaves as the above
> More
I think my brain just assumes that all whitespace after the colon of a
field name and before the first non-whitespace character is ignored, so
doesn't have a problem with that, but I can see why it would be confusing.
> Otherwise, if the current semantics are retained, at least for me, the
> first line behavior really needs to be clarified.
Yes, we should distinguish between formatted text with synopsis and
formatted text without synopsis more clearly. Or, you know, just propose
a new YAML format which would make it trivial to clean up all of these
problems *and* would provide first-class editor support and easy parsing
in every major programming language. :) But that's WAY bigger than this
bug.
> If we end up switching the field semantics, that seems it might cause
> unnecessary modification churn, given that I (not sure whether other
> people have done this before than me as well) at least have "instigated"
> unintentionally this type of change in several places (packages I
> maintain, golang/prometheus team), including tooling (AFAIR dh-make and
> dh-make-golang), and other people might have also picked this up too. :/
I think making the field a line-based list is the obviously correct thing
to do. It's just not backward-compatible, so we will have to face the
question of how we handle a version bump in the copyright file (and of
course figure out if we're going to deal with all of the other requests
that would require a version bump).
And I have packages where individual copyright lines are longer than 80
columns, so we either have to require unwrapped lines greater than 80
columns (which I'd rather not do), or we have to define line wrapping
semantics for line-based lists, which adds yet more irritating ugliness to
the deb822 format. Probably just "if the line is indented by more than
one space, it's a continuation for the previous line" I guess.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
