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
signature.asc
Description: PGP signature
