guix-patches
[Top][All Lists]
Advanced

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

[bug#37224] [PATCH 0/4] Add 'archival' checker for 'guix lint'


From: zimoun
Subject: [bug#37224] [PATCH 0/4] Add 'archival' checker for 'guix lint'
Date: Thu, 12 Sep 2019 11:52:03 +0200

Hi Ludo,

On Thu, 12 Sep 2019 at 09:41, Ludovic Courtès <address@hidden> wrote:

> zimoun <address@hidden> skribis:
>
> > On Fri, 30 Aug 2019 at 01:18, Ludovic Courtès <address@hidden> wrote:
> >
> >> Currently, only 25% of our packages are not fetched with ‘url-fetch’.
> >> For the remaining 75%, this checker can only report whether the tarball
> >> is missing (and apart from ftp.gnu.org and a few other exceptions, it
> >> usually _is_ missing) and cannot actually save it.

And it is interesting that Nix has the same stats. ;-)

https://sympa.inria.fr/sympa/arc/swh-devel/2019-08/msg00024.html


> > Maybe I miss something, but for example guile-2.0 is not yet archived.
> > I am not able to find it with their search resources. And `guix lint
> > -c archival guile@2.0' reports "guile@2.0.14: source not archived on
> > Software Heritage".
>
> Yeah, most not-too-recent tarballs from ftp.gnu.org are archived, so I
> don’t know why this one is missing.  We’d have to check with them.

Maybe I have wrong, but bunch of GNU packages seems missing. :-)


> > I agree with the words on #swh-deve by olasd (Nicolas Dandrimont) from
> > SWH that the automatic "save" should be optional (even if the default
> > is save=true).
>
> Maybe we could have a flag somewhere to turn it off?  The good thing of
> having it on (or opt-out) is that we increase the chances that the code
> we care about is archived.  :-)

I agree. :-)


Speaking of UI, I would expect 2 different commands:

 - one to check if the package is in SWH, say:
    guix package <name> --is-in-swh
 - one to send a "save" request
    guix lint <name> -c archival

And adding an option to turn "the push" off, say:
  guix lint <name> --no-archival

Because when linting the process is generally iterative:
  guix lint <name>
  # fix mistake
  guix lint <name>
 # fix other mistake
 etc.
and it will save network resource (latency, etc.) by avoiding to check
again and again in this lint process; I guess.

Or even something in this flavour should be a better UI:

  guix lint <name> --checkers=description,synopsis
--no-checkers=license,archival

What do you think?



Cheers,
simon





reply via email to

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