guix-patches
[Top][All Lists]
Advanced

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

[bug#53818] [PATCH 0/3] Add Repology updater


From: Ludovic Courtès
Subject: [bug#53818] [PATCH 0/3] Add Repology updater
Date: Thu, 10 Feb 2022 21:49:04 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux)

Hi,

Xinglu Chen <public@yoctocell.xyz> skribis:

> Ludovic schrieb am Dienstag der 08. Februar 2022 um 23:59 +01:

[...]

>> Repology implements the same functionality as our updaters, so
>> repology.org is effectively “service as a software substitute”
>> (SaaSS).
>
> Right, but it tracks a lot more repositories than what our updaters do,
> so why not take advantage of that.

True, but this is kinda self-reinforcing: it’ll sure keep tracking more
if we stop maintaining our own code (IIRC, Repology was started after
‘guix refresh’ and I believe it’s maintained by one person.)

>> My preference would be to keep our existing updaters rather than
>> effectively ditch them and delegate the work to Repology.  It’s tempting
>> to think we can have both, but I’m not sure this would last long.
>
> The point of the Repology updater is to act as a fallback if none of
> the other updaters can update a package, e.g., ‘maven-dependency-tree’.
> I already mentioned that language-specific updaters usually provide more
> accurate and detailed information, so they should be used when possible;
> we aren’t losing anything here.

Hmm yes, could be.  OTOH, like Nicolas writes, we would probably need
some filtering or post-processing to reduce false-positives, right?

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.

Thanks,
Ludo’.





reply via email to

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