GNU bug report logs -
#74542
[PATCH 00/11] Improved tooling for package updates
Previous Next
Reported by: Ludovic Courtès <ludo <at> gnu.org>
Date: Tue, 26 Nov 2024 10:33:01 UTC
Severity: normal
Tags: patch
Done: Ludovic Courtès <ludo <at> gnu.org>
Bug is archived. No further changes may be made.
Full log
Message #199 received at 74542 <at> debbugs.gnu.org (full text, mbox):
Hi Ludovic,
Ludovic Courtès <ludo <at> gnu.org> writes:
> Maxim Cournoyer <maxim.cournoyer <at> gmail.com> skribis:
>
>>> @@ -253,6 +254,23 @@ (define* (fold-packages proc init
>>> init
>>> modules))
>>>
>>> +(define all-packages
>>> + (mlambda ()
>>> + "Return the list of all public packages, including replacements and hidden
>>> +packages, excluding superseded packages."
>>
>> Reading the above doc made me question; are replacements always supposed
>> to be made public? I typically would leave them private to avoid
>> cluttering the CLI with duplicate packages.
>
> Replacements are always reachable via the ‘replacement’ field, whether
> they’re public or not.
>
> If they’re public, they’re also visible from the user interface, which
> is probably nicer. Other than that, it doesn’t make a big difference.
I see, thanks for explaining. Assuming they have the same name, the
interface for 'guix search $name' would now should two versions
available, while in theory if you 'guix shell $name <at> older-version' you'd
get the graft anyway, which is at the newer (fixed) version.
And, 'guix build $name', although the CLI would say version is Y, would
actually show version X in the store, which could be confusing in some
cases.
Both have good and bad points... I'm not too sure which one is
preferable. Probably, as you said, seeing the newest version which is
used on the CLI is preferable to seeing the same version match in the
package store file name, so I think I'll make replacements public from
now on... another thing to document some day!
--
Thanks,
Maxim
This bug report was last modified 169 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.