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