Re: Reverse the naming of store items?

[Kaelyn]

On Saturday, December 4th, 2021 at 7:04 AM, Jacob Hrbek 
<kreyren@rixotstudio.cz> wrote:

> Currently we use 
> /gnu/store/zzz16sfz4jxsdvf8j29rkd46psrc6dpj-emacs-ert-runner-0.8.0.drv for 
> store items which are painful to navigate from CLI using bash's 
> auto-completion as the first letter doesn't correspond to the package name 
> which usually requires doing `ls /gnu/store | grep emacs` and then copy 
> pasting the path to work with the store items.
>
While I agree the store paths are a pain to work with from the CLI and could 
make CLI interactions a bit easier, I don't think reversing the name of the 
store items willresolve the issue of knowing the correct package path. 
Specifically, as package dependencies and derivations change over time, the 
hash changes without the package name or version changing. For example, on a 
computer I switched to GuixSD 3 or 4 months ago currently has 25 different 
hashes for mesa 20.2.4 (as seen from "ls -d /gnu/store/*mesa-20.2.4") and three 
more for mesa 21.2.5 from switching to core-updates-frozen. So using the latter 
as example, "ls -d /gnu/store/*mesa-21.2.5" currently yields:

/gnu/store/5sbldxhgxwn2cjlkgak8sz1xms5paw2b-mesa-21.2.5/
/gnu/store/ibcvamhixj4gnxbimgzgb7hga01wa7fw-mesa-21.2.5/
/gnu/store/yai19kghj02lkp8g5rjh28qwyp3i7ik4-mesa-21.2.5/

Reversing the names won't solve the issue of which is the correct/current 
version. Following the same example, "guix build -n mesa" prints out the path 
corresponding to the current generation of "guix pull":

25.2 MB would be downloaded:
   /gnu/store/irq1fkfd4cg78qscycjzxy1nzf0n8j9m-mesa-21.2.5-bin
   /gnu/store/5sbldxhgxwn2cjlkgak8sz1xms5paw2b-mesa-21.2.5

(The message about the downloads is because the "*-bin" output isn't currently 
in my /gnu/store.)

In the simplest cases picking any one of the three could work, though even then 
there could be library version conflicts if the picked version uses 
older/different libs than what your environment has (for mesa, that could be 
VDPAU_DRIVER_PATH pointing to a directory with incompatible modules; for 
python, that could be PYTHONPATH referring to the wrong python site directory 
such as "~/.guix-profile/lib/python3.8/site-packages"). In this case, because I 
also have wine installed, one of the three mesa-21.2.5 directories is not even 
the same architecture as the others:

$ file /gnu/store/*mesa-21.2.5/lib/libGL.so.1.2.0
/gnu/store/5sbldxhgxwn2cjlkgak8sz1xms5paw2b-mesa-21.2.5/lib/libGL.so.1.2.0: ELF 
64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, not 
stripped
/gnu/store/ibcvamhixj4gnxbimgzgb7hga01wa7fw-mesa-21.2.5/lib/libGL.so.1.2.0: ELF 
32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, 
not stripped
/gnu/store/yai19kghj02lkp8g5rjh28qwyp3i7ik4-mesa-21.2.5/lib/libGL.so.1.2.0: ELF 
64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, not 
stripped

That isn't to say I disagree with reversing the naming or other improvements to 
the CLI experience, because I do agree it could use some QoL polish. I only 
wanted to chime in about the complexities of providing better integrations.

Cheers,
Kaelyn

> Would it break anything if we changed the metadata order like: 
> /gnu/store/emacs-ert-runner-0.8.0-zzz16sfz4jxsdvf8j29rkd46psrc6dpj.drv ?
>
> -- Jacob "Kreyren" Hrbek
>
> Sent with ProtonMail Secure Email.