Hi! On Sun, 2022-09-18 at 10:42:28 -0700, Russ Allbery wrote: > Guillem Jover <guil...@debian.org> writes: > > > These are the set of changes I keep doing to the debian/copyright files > > I end up touching. While some could be characterized as a subjective > > style issue, I've tried to give as close as possibly objective :) > > rationale for every and each of the changes in the commit messages which > > I'll summarize here. > > Thanks! I have applied these changes for the next release except for > patch 0002 (applying wrap-and-sort -sat). > > I agree with patch 0002 for Files, but unfortunately I believe it's > incorrect for Copyright. You're treating Copyright as if it were a > line-based list field, but for better or worse (I think probably for > worse) the current specification says that it's a formatted field.
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. :/ > This means that your change to, for example: > > Copyright: > 2008 John Doe <j...@example.com> > 2007 Jane Smith <jsm...@example.org> > 2007 Joe Average <j...@example.org> > 2007 J. Random User <j...@users.example.com> > > means that the semantic content of that field is now: > > 2008 John Doe <j...@example.com> 2007 Jane Smith <jsm...@example.org> > 2007 Joe Average <j...@example.org> 2007 J. Random User > <j...@users.example.com> > > and a format-aware display engine should show it as such. This is the > reason why lines are indented: that makes them verbatim lines per the > formatting specification in > https://www.debian.org/doc/debian-policy/ch-controlfields#s-f-description 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 would agree with changing the definition of Copyright to a line-based > list, although in order to do so we'd have to figure out the implications > of a format change in the specification, and we should also flesh out the > definition of a line-based list to explain how to handle a line that's > longer than the normal wrap length. Right, I'd prefer this too, but obviously that is more involved than what this report intended to be. So I guess it should be detangled into another request. Otherwise, if the current semantics are retained, at least for me, the first line behavior really needs to be clarified. On Sun, 2022-09-18 at 10:58:20 -0700, Russ Allbery wrote: > Russ Allbery <r...@debian.org> writes: > > I would happily apply a version of 0002 that only changes Files and > > leaves Copyright alone. I can split that up, for an incremental update yes. Will send later. > Or, perhaps even better, one that changes Copyright the way that you did, > but just adds an extra space. I think that's the simplest compromise > between what you're trying to accomplish and the field definition. 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. :/ Thanks, Guillem
