GNU bug report logs - #53818
[PATCH 0/3] Add Repology updater

Previous Next

Full log

Message #167 received at 53818 <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: Nicolas Goaziou <mail <at> nicolasgoaziou.fr>
Cc: 53818 <at> debbugs.gnu.org, Xinglu Chen <public <at> yoctocell.xyz>
Subject: Improving updaters and ‘guix refresh’
Date: Tue, 15 Feb 2022 10:57:10 +0100

Hi!

Nicolas Goaziou <mail <at> nicolasgoaziou.fr> skribis:

> Ludovic Courtès <ludo <at> gnu.org> writes:
>
>> (I’m confused because my understanding of what you first wrote was that
>> Repology had too many false positives to be useful.)
>
> Repology is okay for my use-case because I've gotten accustomed to its
> quirks. I wouldn't recommend it as a fall-back solution for Guix in its
> current form, tho, for the reason above. Does that make sense?

It sure does, thanks for explaining.

> I wrote about the following facts:
> - it is difficult to specify a large number of packages,
> - when you have specified a large number of packages, the processing is
>   slow,
> - checking GitHub fails for me.

Alright, I had missed that.

Regarding “specifying many packages”, do examples like these work for
you:

  • guix refresh -t elpa

  • guix refresh $(guix package -A ^emacs- | cut -f1)

  • guix refresh -r emacs-emms

  • guix refresh -s non-core -t generic-git

  • guix refresh -m packages-i-care-about.scm

If not, what kind of selection mechanism could help?  ‘-s’ currently
accepts only two values, but we could augment it.

Regarding slow processing, it very much depends on the updater.  For
example, on a warm cache, ‘guix refresh -t gnu’ is relatively fast
thanks to caching:

--8<---------------cut here---------------start------------->8---
$ time guix refresh -t gnu
gnu/packages/wget.scm:48:13: wget would be upgraded from 1.21.1 to 1.21.2
gnu/packages/tls.scm:86:13: libtasn1 would be upgraded from 4.17.0 to 4.18.0

[...]


real	0m38.314s
user	0m38.981s
sys	0m0.164s
--8<---------------cut here---------------end--------------->8---

It could be that some updaters do many HTTP round trips without any
caching, which slows things down.

[...]

>> Do you have examples of what’s wrong on the UI side?
>
> It has no Emacs interface. Nuff said. ;)

True!  :-)

I realize this is going off-topic, but let’s see if we can improve the
existing infrastructure to make it more convenient.

Thanks,
Ludo’.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.