Meeting started at 2024-06-20 16:00:59 UTC

The Meeting name is 'fpc'

!hi

James Antill (james)

!hi

Carl George (carlwgeorge) - he / him / his

!hi

Neil Hanlon (neil) - he / him / his

Carl George: How much do you not want to comment on issue 1373?

🤯

!hi

Fabio Valentini (decathorpe) - he / him / his

!hi

Neal Gompa (ngompa) - he / him / his

fwiw I don't understand the hype around nix

maybe I reached "old man yelling at clod" stage of my life though

same

regardless, people do love it, and it would be beneficial to them to be able to `dnf install nix`

true. better than curl | bash

or whatever you need to do to get it

I'd really like to know if it really is that difficult to move `/nix` to `/var/nix`

!hi

i think i'm ok with an exception to let it have `/nix`. the other suggestions in the issue don't seem worth it if we're just gonna bind mount it to `/nix` anyways.

Jonathan Steffan (jsteffan)

because the last time we had this discussion was over `/snap`

and frankly, the same arguments kind of apply

what was the outcome for snaps?

`/snap` was banned and snapd changed to use a subdir in `/var`

`/var/lib/snapd/snap` was what was picked

nix packages that hard-code paths in /nix/store is going to be a problem

not sure if that was a problem for snap too?

it's a union mount of squashfs images in their own mount namespace

they don't actually see anything

only "classic" snaps need `/snap` and a symlink does fine for that

but those types of snaps are supposed to be rare

Anyone have a guess if /nix could work on ostree?

I believe no

same reason classic snaps don't work either

top level mount is a no-no

well isn't that ironic 🎶

Yeh, my assumption is it doesn't work now ... was just wondering if it was even plausible it might be made to work?

or rather new FHS dirs breaks things for rpm-ostree (which is ironic since it forces `/sysroot` itself)

and nobody ever asked us about that :/

Not that Colin deserves it, but a significant part of me would be fine just pointing at ostree and saying it's not possible.

yeah ... rpm-ostree limitations are not a good reason to *not* do something that works in other environments

It's well known that all the cool kids want tar files now, our fault for choosing cpio files ... we should have known what would be cooler.

but looking briefly at nix, it seems the nix store location is configurable

and if some nix files don't handle that properly, I would probably suspect that's an error on their part

(to clarify, build-time configurable, not runtime configurable)

I read parts of the thread posted ... and it looks like people have changed the location ... it just makes it incompatible with the "normal nix" packages. But I'm a little confused about how that works anyway.

a packaged nix command that is incompatible with most nix packages that are out there doesn't seem very useful

right ... if you'd need to patch or recompile stuff you lose most of what makes it interesting

So ... it's been a long time and I might be confused, but ... AIUI if you use "normal" nix to install things on Fedora, it's not going to use any of Fedora. Eg. you'll get an extra copy of glibc/fileutils/etc. which are the nix deps versions?

well, kind of?

unless it's all compiled and RPATH linked correctly (and not all nix stuff is), it can use system stuff

and Nix can be useful even in the case where you're not using it to use cached binary builds of nixpkgs, because it essentially composes something for you (whether that's an application, an image, an RPM, or something else)

I guess I'm just a bit confused about what they want to do, and how they want it to act. Is "yum install nix" just a better way of starting than "curl -L https://nixos.org/nix/install | sh" ... but everything after that will be the same?

right. setting up a whole development environment is also a common use

we could say it's better to live in a copr until the upstream makes a final decision on the relocation?

well, the thing is, nix packages aren't supposed to be dependent on a particular store location

https://nix.dev/manual/nix/2.22/store/types/

seems they are though, based on the comment in the issue

Eh, I feel like if that's our only concern then we should say that and it will help upstream ... but if we aren't going to allow it anyway then we should state that before they do a bunch of work that won't help them.

I'm not in favor of allowing `/nix`

considering that we defacto allow `/sysroot` for rpm-ostree (even if they never asked), it might be perceived negatively if we don't allow `/nix`

by that token we'd need to reverse `/snap`

and allow it too

ok

at the end of the day, allowing `/nix` doesn't hurt anything

well, it breaks rpm-ostree

the nix package can never be installed on rpm-ostree systems

nor composed in it

so far, we have bent over backwards to ensure we don't do that

for everyday run of the mill packages, following fhs is good hygiene, but for ecosystem stuff like this exceptions make sense to me

that's why we aren't even allowed to use Lua scripts in systemd and have horrible bash ports

And I assume that also affects silverblue and bootc/etc.

yes

at least for the near future

bootc will eventually not require /sysroot

since there's no ostree involved

since rpm-ostree will be phased out for bootc, it's a non-issue long-term

we could ask some of the ostree folks to comment on the issue from their perspective to gather more data before a decision

I'd rather ask the Nix people to consider moving the default nix store to `/var/nix` or ask them whether they consider a nixpkg broken in an alternate store location a bug or not

because based on the documentation it should be at least the latter

and if that's true, then ecosystem or not, bad packages are not a good enough reason to allow it

i guess file it as a bug and see if they close it wontfix or not

I'd hope they wouldn't, because they already support alternative nix store locations for global and per-user locations

what you're saying seems to conflict with what egoode put in the issue

my understanding is that Nix is fundamentally source based with a binary cache system

so the main issue with changing it without getting upstream to agree to change it too is that their cache is invalidated unless Nix gets handling to transpose it

From the linked thread, I understand that it's impossible to handle a change without recompiling packages.

it looks like upstream Nix has been actively discussing the problem for a while

one of the most recent discussions: https://github.com/NixOS/nix/issues/9549

hardcoding the store path rather than having it be configurable seems like a pretty big design flaw to me

since we're running out of time, and we don't seem to be anywhere close to a decision on this, should we call it for now?

there is an RFC to move it to `/var/lib/nix` seemingly: https://github.com/NixOS/rfcs/pull/17#issuecomment-629776797

I think it might make sense for one of us (I can do it) to go and talk to Nix people upstream

Yeh, although I will also mention that while nix has been around for a long time now ... you might be surprised what rust-nix-devel does.

I think if you are volunteering, you are the only one ;)

there's a fair bit of threads all over discussing moving out of `/nix`

it breaks macOS, it breaks Atomic Fedora, etc.

(those are two explicitly called out examples, but I know of more, like openSUSE MicroOS)

heh

the hungry, tired, and worn state of post-conference leads to weird stream of consciousness

That's fair ... I shouldn't give you a timed exam on guessing what the package described as "Python bindings for NIX" does then?

lol