Re: Reverse the naming of store items?

[Kaelyn <kaelyn.alexi@protonmail.com>]

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.