[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Automated copyright reviews using REUSE/SPDX as alternative to DEP-5



Quoting Stephan Lachnit (2022-02-10 11:59:11)
> On Tue, Feb 8, 2022 at 8:36 PM Jonas Smedegaard <jonas@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

Attachment: signature.asc
Description: signature


Reply to: