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

Previous Next

Full log

View this message in rfc822 format

From: Nicolas Goaziou <mail <at> nicolasgoaziou.fr>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 53818 <at> debbugs.gnu.org, Xinglu Chen <public <at> yoctocell.xyz>
Subject: [bug#53818] [PATCH 0/3] Add Repology updater
Date: Mon, 14 Feb 2022 11:40:34 +0100

Hello,

Ludovic Courtès <ludo <at> gnu.org> writes:

> Do you have examples where our updaters perform poorly and where
> Repology does a better job?  I wonder if there are lessons to be drawn
> and bugs to be fixed.

As a data point, I'm sorry to say that our updaters are useless to me.

I watch over more than one thousand packages. I would have a hard time
expressing what are those packages to the updater, besides writing and
keeping up-to-date a huge manifest file. Assuming I could manage this,
fetching all version information would take considerable time, and,
since many packages are from GitHub, the party would stop early anyway
with GitHub refusing to proceed and requesting some token I don't have.

OTOH, using Repology API, I get the information I want in about ten
seconds. Sure, I need to eyeball through the results, filtering false
positives (around 4% in my case), but it still is a practical solution.

IMO, to be useful, updaters may need to rely on an external service,
which may, or may not, belong to the Guix ecosystem. They also need
a good UI.

I don't want to sound too negative, though. And current updaters are
certainly good enough when watching over a couple of packages, which
might be the most common use-case.

Cheers,
-- 
Nicolas Goaziou

Previous Next

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