Reverse the naming of store items?

Reverse the naming of store items?

[Jacob Hrbek]

[-- Attachment #1.1.1: Type: text/plain, Size: 554 bytes --]

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.

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.

[-- Attachment #1.1.2.1: Type: text/html, Size: 862 bytes --]

[-- Attachment #1.2: publickey - kreyren@rixotstudio.cz - 0x1677DB82.asc --]
[-- Type: application/pgp-keys, Size: 737 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 249 bytes --]

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.

Re: Reverse the naming of store items?

[Vagrant Cascadian]

[-- Attachment #1: Type: text/plain, Size: 1873 bytes --]

On 2021-12-04, Jacob Hrbek 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.

I would welcome changes like this, although the last time I brought it
up, it was mentioned that there was some sort of optimization done that
took advantage of the first N characters being a fixed length...

Some workarounds:

* make a symlink farm somewhere else that pointed to all the store items

* write a fuse filesystem that reorders the paths

* write an emacs mode that allows you to browse the tree with a
  different view of the paths


> Would it break anything if we changed the metadata order like:
> /gnu/store/emacs-ert-runner-0.8.0-zzz16sfz4jxsdvf8j29rkd46psrc6dpj.drv
> ?

It would trigger a world-rebuild event, as everything references paths
by the existing names...


While we're on the topic of such massive changes, I'm also partial to
splitting into subdirs, for the cost of one extra character, you could
have:

  /gnu/store/z/zz16sfz4jxsdvf8j29rkd46psrc6dpj-emacs-ert-runner-0.8.0.drv
instead of:
  /gnu/store/zzz16sfz4jxsdvf8j29rkd46psrc6dpj-emacs-ert-runner-0.8.0.drv

This might provide improved performance on some filesystems (e.g. ext4
fsck uses huge amounts of memory with very large numbers of files in a
single directory), and would potentially allow to split the store across
multiple filesystems... although maybe that would be difficult to
actually do.


Though... my guess is such core changes just will not happen unless
there is a strongly compelling reason to do so as it would be a very
expensive transition.


live well,
  vagrant

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]

Re: Reverse the naming of store items?

[Mark H Weaver]

Hi Jacob,

Jacob Hrbek <kreyren@rixotstudio.cz> writes:

> 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.

As Kaelyn pointed out, there will usually be more than one store item
for the same package, so you'll need to know at least the first few
characters of the hash.  Once you have that, then you will also have the
entire store item name on your screen, at which point you can copy+paste
it into your shell session.

Suppose you don't want to copy+paste it.  If you know the first few hash
characters, then you can simply type "/gnu/store/<first hash chars><TAB>"
and that will usually be sufficient.  For example, suppose I wish to
navigate to the store item of the emacs that I'm currently using to type
this message, which is:

  /gnu/store/9a31k78k56ky1da7n7knq3ys9hriw5sj-emacs-next-pgtk-28.0.50-1.ae18c8e

On my current system, it suffices to type:

  /gnu/store/9a31 <TAB>.

If your proposal were adopted, then I would instead need to type:

  /gnu/store/emacs-ne <TAB> 9 <TAB>

That's 6 more keypresses than is required under the current approach.

      Regards,
        Mark

-- 
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about <https://stallmansupport.org>.