[Top][All Lists]

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

[bug#34449] [PATCH] gnu: Add trydiffoscope.

From: Leo Famulari
Subject: [bug#34449] [PATCH] gnu: Add trydiffoscope.
Date: Tue, 12 Feb 2019 15:37:42 -0500
User-agent: Mutt/1.11.2 (2019-01-07)

On Tue, Feb 12, 2019 at 12:16:42AM -0800, Vagrant Cascadian wrote:
> On 2019-02-12, Julien Lepiller wrote:
> >>+    (synopsis "Compare files and archives in depth")

This synopsis doesn't make clear that this is a client for a remote
service. Can you rewrite it?

> >>+    (description
> >>+     "This is a minimal diffoscope client that connects to the
> >>service:

Also, I think it's better to replace "diffoscope client" with something
like "client for the remote diffoscope service located at [...]" since
diffoscope is not inherently a client-service tool. Also it would be
great to mention the full diffoscope package :)

Can you send an updated patch?

> > Iiuc, this is a client to connect to a service that runs diffoscope
> > for you. But we already have diffoscope, so what's the point?
> Yes, that's the jist of it.  The main advantage is that it has a much
> smaller dependency chain locally.
> I find it useful on some of the not-particularly-fast ARM systems I've
> been running GNU Guix, where storage may be limited or slow, and
> substitutes may not be available as often, and build times
> are... remarkable.

Yes, and diffoscope runs can also be really expensive. It's nice to
offload them.

Also, if the service makes statements about whether submissions are
logged or made public, can you put that in the package description?

> > Also this looks like saass to me, so I think we should refrain from
> > adding it to guix.
> It is essentially SaaSS.  The server-side is at least licensed under the
> AGPL, if that mitigates concerns somewhat.
> I'm not sure it supports it out of the box yet, but I suspect upstream
> would be amenable to patches to make it easy for people to run their own
> "diffoscope" services.
> > What do you think?

We can have SaaSS in Guix. There are already some packages that are
SaaSS. So I think this package is okay.

It's "extra okay" in my opinion since the service is AGPL, part of
Debian, and we have a package for the tool in question.

Guix is developed under the Free System Distribution Guidelines, which
don't mention remote services or SaaSS at all:

And some discussion on the subject of services in the context of free
software that largely reflect how we handle SaaSS in Guix:

Attachment: signature.asc
Description: PGP signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]