On Sun, Sep 18, 2022 at 06:01:38PM -0700, Russ Allbery wrote:
> 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're going to do that, it might make sense to explicitly allow JSON
and/or TOML as alternative representations, because there are some
really weird edge cases in YAML.
> > 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).
I think semantic versioning would require you make this a major version
bump, since like you say it's not backwards compatible.
> 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.
Ah yes, but then if you do that, the old examples in policy that were
being patched away here (usage of which might exist in the wild) would
now have different semantics...
--
w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}
I will have a Tin-Actinium-Potassium mixture, thanks.
