Quoting Stephan Lachnit (2022-02-10 11:59:11) > On Tue, Feb 8, 2022 at 8:36 PM Jonas Smedegaard <jo...@jones.dk> > wrote: > > > > For starters, the format adds one SHA1 hash per source file, right? > > Yes, one checksum per file. > > > Sure I can "just" ignore all FileChecksum: lines, but anyone working > > with XML will know that plaintext does not equal human-readable. > > This comparison is a bit off, XML is a representation. The SPDX format > I want to use is tag:value just like DEP5, so in this regard > "human-readable". There is more cruft content, but it takes less than > 5 minutes to understand where the per file copyright and license > information is.
It takes less than 5 minutes to understand where the per file copyright and license information is: "Just" ignore all angle-bracket markup. Comparison is that both XML and checksums adds noise, reducing readability. ...and seems you agree: > Yes I agree that adding hashes to DEP5 makes it unreadable and utterly > annoying to maintain, that's why I don't want to add it. DEP5 is > designed to be written by humans, SPDX is not. That's why SPDX can add > hashes without any drawbacks. A file containing checksums for all files is much harder not only to write but also to read, than one without such hashes. [ original criticism revived ] Quoting Jonas Smedegaard (2022-02-08 16:39:36) > If we permit a debian/copyright format that is not human-readable, it > means that I cannot confidently proof-read and change the contents of > the debian subdir without the help of machine-parsers, and I would > need to know two formats with different goals. > > > I don't see the problem with machine parsers. We already use a lot > > > of different tools for our processes (git, dput, dpkg, debhelper, > > > lintian, uscan, a mail program, a text editor, ...), adding one > > > more shouldn't be a big deal. It needs to be provided of course, > > > but I plan to do that. > > > > Only 2 of those you list are mandatory: dpkg and RFC822 email - the > > rest are optional, some quite popular but even then routinely > > bypassed. > > I mean if you want you can write SPDX files by hand, it's not a binary > format. Same as you can write a Debian package without debhelper. I can also transfer TCP packets using pigeons, if I seek challenges. My concern is not about binary versus text-based format, but about only-machine-readable versus human-and-machine-readable format. > > I would be quite happy if our work on evolving debian/copyright would > > result in a future revision being identical to REUSE format. > > > > What I dislike is requiring all developers to master 3 formats instead > > of currently only two: freeform-human-only and (also-)machine-readable. > > No, you don't have to master SPDX! That's the point: you don't > interact with it at all. It's created by tools, and shipped to satisfy > the legal obligation to provide copyright information. Users don't > care how the copyright information is shipped. As a developer, you > just have one less thing to care about, namely writing > debian/copyright by hand. I need to either interact with the format or depend on tools that do. When I release a package to Debian, then I am responsible for that package being in compliance with Debian Policy - including ยง 2.3 about information that the debian/copyright file MUST cover. It does not matter if I write debian/copyright by hand or choose to use automated tools to autogenerate that file - regardless it is my responsibility to ensure that contents or that file comply with Debian Policy. If I upgrade a package as an NMU, then it is my responsibility to ensure that the new package comply with Debian Policy - including debian/copyright getting updated as needed - but if debian/copyright format is alien to me then I cannot do that responsibly. Your argument seems to be that I can simply trust SPDX/REUSE tools. Agreed, I can choose to trust tools doing magic for me, but that is exactly my concern: I am _forced_ to trust tools, where I have the (easy!) option of by-passing helper tools with current [also-]machine-readable format. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private
signature.asc
Description: signature