unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Vagrant Cascadian <vagrant@debian.org>
To: Jacob Hrbek <kreyren@rixotstudio.cz>,
	"guix-devel@gnu.org" <guix-devel@gnu.org>
Subject: Re: Reverse the naming of store items?
Date: Sat, 04 Dec 2021 12:01:12 -0800	[thread overview]
Message-ID: <877dckqgvr.fsf@ponder> (raw)
In-Reply-To: <bGRUcQCdz4lOE_PP7F9TPpLAVE4Qbkn85QY1PnDvtakBteQGJ_SxcnkGBmPnBw0_r0NUxPMlUcQLprYwFE7ZDwsFlMzwoTl3cAUwxBD_lzI=@rixotstudio.cz>

[-- 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 --]

  parent reply	other threads:[~2021-12-04 20:02 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-04 15:04 Reverse the naming of store items? Jacob Hrbek
2021-12-04 19:16 ` Kaelyn
2021-12-04 20:01 ` Vagrant Cascadian [this message]
2021-12-05  1:15 ` Mark H Weaver

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=877dckqgvr.fsf@ponder \
    --to=vagrant@debian.org \
    --cc=guix-devel@gnu.org \
    --cc=kreyren@rixotstudio.cz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).