all messages for Guix-related lists mirrored at yhetil.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

* 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 external index

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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.