fesco

#3473 Exception request for /nix
Closed: Accepted by zbyszek. Opened by zbyszek.

Closed: Accepted
Reopen Issue

Over the years there were multiple attempts to get nix (the code and the packages) available in Fedora. We are nearing the end of a review of nix (https://bugzilla.redhat.com/show_bug.cgi?id=2388768) and and the package should be able to create /nix/store and the rest of the /nix hierarchy.

As explained in https://pagure.io/packaging-committee/issue/180:

Nix uses the /nix directory by default for essential operations — its package store, for instance, is located at /nix/store by default, and it's local state in /nix/var.

These can be overridden at compile time, however, doing so makes it [http://hydra.nixos.org/build/2657151/download/1/manual/#id523917 impossible to use pre-built binaries] provided in Nix channels (repositories).

In https://pagure.io/packaging-committee/issue/1373, the FPC stated:

You can ask FESCo for an exception, but we don't think we should grant it

I understand why FPCs wants this redirected to FESCo. FPC purview is how to correctly package software in the current system, but adding support for Nix is a higher-level decision. Should we attempt to make nix packages easy to use on Fedora? Should we try to force nix to change the prefix path they are using? Etc.

While it is technically possible to use nix without the cache, it's much slower. Any user would strongly prefer to have the cache available. Hence this request to allow the top-level directory to be created. And I think trying to force the nix ecosystem to change to a different prefix is futile, for exactly the same reasons.

History and previous concerns: in the first ticket, it seems very little thought was given to the request. It was just a knee-jerk reaction: "not in FHS → reject". In the second ticket, doubts were expressed if anybody actually would want to use it: "It's not entirely obvious why people want 'nix' as a package in Fedora", "From what I can see nix can't easily be used to install extra things". This is unjustified. Even the fact that people have been trying to push this through FPC for 13+ years and that there are at least three COPRs with nix and multiple attempts at package review have been made over the years should be enough to justify that clearly people want to use this. And installing packages is as trivial as nix-shell -p cowsay -p lolcat (example from the docs, which instantiates an environment with those two programs and launches a shell in it.)

Note that users obviously can always create the /nix hierarchy after package installation. They can do that manually, also Jens Petersen's COPR repo provides a helper package. But I think there are strong reasons to allow the official Fedora package to do this automatically. If the installed package works out-of-the-box, this makes for a much better UX. Having to enable an additional COPR repo and execute some special commands raises the bar for newcomers. Also, Fedora now provides a good base to build and test for other distributions. We provide installers for almost all types of Linux distro packages (dpkg and apt, apk, flatpak, snap, pacman, zypper, and probably a few others I forgot). This makes a normal Fedora installation an excellent development environment. The lack of nix is a significant gap. Nix project provides the biggest distribution of binary packages (100k+) and an innovative take on the packaging problem. Using Fedora as a base for CI and other automated deployments if much easier and more robust if the complete solution is provided by the distro package.

Thus, I'm requesting the following exception:
~~ > /nix top-level directory may be used for Nix runtime and package store. It shall not be part of the filesystem package, but packages are allowed to create it.~~

v2:

/nix top-level directory may be used for Nix runtime and package store. It shall not be part of the filesystem package, but packages are allowed to create it. It should be created as a subvolume on filesystems that support this (btrfs).

(I think it's enough if FESCo makes just the top-level decision. The details can be hammered out based on implementation experience and in cooperation with the FPC.)

/cc @petersen

We actually said no to /snap almost ten years ago on pretty much the same grounds in #1614.

The result was that they developed the /var/snap path as an alternative. I'm still not convinced that we should grant /nix because it's even more obvious that Nix is functional with another path. And if we grant this, we will need to revisit #1614 because now we've invalidated the reasoning for that.

Of course, another option would be to request /snap and /nix as paths for FHS 4.0 and declare them reserved for these purposes. If that happened, we'd probably accept them in Fedora.

I'm still not convinced that we should grant /nix because it's even more obvious that Nix is functional with another path.

In theory yes, but in practice unfortunately any location other than /nix is basically useless since any pre-built (cached) binary artifacts (eg from https://cache.nixos.org or https://cachix.org etc) require /nix/ in order to be valid for use.
Edited by petersen

While I'm definitely in favor of standardization, there's a certain amount of practicality that also has to be accounted for. If an entire ecosystem exists around the presence of this directory, then it's probably not realistic for us to demand they change to comply with decades-old rules.

Looking back on #1614, I was definitely of a different mind on this topic nine years ago. I realize that my view here is inconsistent, but I'm not quite the inflexible standards-conformist I once was.

I would like to see some consistency on actual disk storage, so that we aren't introducing a completely new partitioning layout for our users. So, rather than have the /nix directory being mounted directly at the root, I'd prefer for us to ship a symlink (or symlinks, if there are pieces that belong split between /usr and /var) that points into the appropriate location in the traditional hierarchy. Is that something we could consider? If we did it that way, the /nix path could be treated more as a compatibility layer rather than a traditional mount point.

OK, I'll try to figure out the details here and if a symlink works as expected. Please give me a few days.

My feeling is it would have to be bind mount - I doubt a symlink would cut it (though happy to be wrong)

Metadata Update from @humaton:
- Issue tagged with: meeting

Metadata Update from @humaton:
- Issue untagged with: meeting

Fedora ships Btrfs by default - /nix could just be a Btrfs subvolume right? And if we later decide it cannot be there then it's simpler to just remount it elsewhere.

Fedora ships Btrfs by default - /nix could just be a Btrfs subvolume right? And if we later decide it cannot be there then it's simpler to just remount it elsewhere.

Although btrfs is the default, it is not the only option. What happens if the user decides for a different filesystem?

Metadata Update from @humaton:
- Issue tagged with: meeting

Sorry for the delay.

It seems that a "real" directory is really needed. This directory could be a bind mount,
or a btrfs subvolume, I think nix doesn't care. But a symlink is not good. The manual says [1]:

Normally, the Nix store directory (typically /nix/store) is not allowed to contain any symlink components. This is to prevent “impure” builds. Builders sometimes “canonicalise” paths by resolving all symlink components. Thus, builds on different machines (with /nix/store resolving to different locations) could yield different results. This is generally not a problem, except when builds are deployed to machines where /nix/store resolves differently. If you are sure that you’re not going to do that, you can set NIX_IGNORE_SYMLINK_STORE to 1.

So while we could use a symlink, the packages that would be built would sometimes hash differently, causing interoperability problems. We'd still need to put the symlink in /, which mostly defeats the purpose.

I also don't think we should use a bind mount. This would bring quite a bit of complexity for questionable benefit. A bind mount still needs the directory to mount over to be created. I think that for people using nix, the store should be treated similarly to the main system installation in /usr, so I don't think we should be trying to push it out to /var or some place like that. For people using it, it's part of the "installed system" and provides binaries and such, i.e. it's akin to /usr/local, just with an annoying path.

OTOH, I like the idea of making this a btrfs subvolume (on systems with btrfs). We could use a tmpfiles snippet with q /nix. On other filesystems this will automatically "downgrade" to a plain directory.

I'll edit the top post to mention the idea with subvolumes. Otherwise, the request stands.

[1] https://nix.dev/manual/nix/2.32/command-ref/env-common#env-NIX_IGNORE_SYMLINK_STORE

EDIT: I forgot to add: if we used a symlink, we'd need to put NIX_IGNORE_SYMLINK_STORE=1 in the environment, which is meh.
Edited by zbyszek

Updating to note that we agreed this exception in last week's meeting (2025-10-14)

AGREED: /nix top-level directory may be used exclusively for Nix runtime and package store. It shall not be part of the filesystem package, but packages are allowed to create it. (+6, 1, -0)

I don't recall us specifying any documentation requirement, I guess the FESCo ticket is sufficient?

Metadata Update from @salimma:
- Issue untagged with: meeting
- Issue close_status updated to: Accepted
- Issue status updated to: Closed (was: Open)

No, it needs to be documented with other FESCo exceptions.

@zbyszek can you take care of the documentation?

Metadata Update from @salimma:
- Issue status updated to: Open (was: Closed)

Metadata Update from @salimma:
- Issue tagged with: document it

I looked into this, and then I noticed that my pull request to switch to LFSH from FHS is pending before FPC and I filed https://pagure.io/fesco/issue/3490. Both touch the same paragraph of text so I'd prefer to get that accepted by FESCo too to avoid duplicate work.

Since the other PR is blocked, I submitted https://pagure.io/packaging-committee/pull-request/1504 separately.

PR was merged.

Metadata Update from @zbyszek:
- Issue untagged with: document it
- Issue close_status updated to: Accepted
- Issue status updated to: Closed (was: Open)
Metadata
None
None
None
None
None
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.