[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Reverse the naming of store items?
From: |
Kaelyn |
Subject: |
Re: Reverse the naming of store items? |
Date: |
Sat, 04 Dec 2021 19:16:24 +0000 |
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.