rename openzfs_unstable to openzfs_staging

[cafkafk]

Issue description

Currently, the naming of openzfs_unstable doesn't actually reflect any upstream convention. Besides, it's updated to reflect the latest staging branch version in openzfs, making naming that reflects this much clearer.

Personally, when I started using openzfs_unstable, I found the naming confusing, and finding adequate documentation to explain it's functioning was hard. I think by naming the package after what it targets upstream, we make it much easier for users to understand the intention of the package.

See additional discussion here: #341596

[amarshall]

Well it’s not openzfs_, just zfs_ :)

I agree the name is not the best. The thing I like about “unstable” is that it (I hope) implies some, well instability in it. It is pre-release software, and there are risks with that. (Personally, I think it’s a bit crazy to run a pre-release version of a filesystem just to use a newer Kernel version, but that’s me, and everyone has different trade-offs for their use-cases.)

Some trouble comes in in the current scenario, where it’s a “real” tagged pre-release rather than just a branch tip. I think also some may view a major or minor release (e.g. 2.2→2.3-rc) as different than staging for the next point release. I don’t really know of any other packages in nixpkgs that have this issue—most of them, I think, have their pre-release version be a semi-arbitrary recent commit on e.g. master.

I’ve updated the package description in #352386 a bit to clarify, let me know what you think there.

[cafkafk]

Personally, I think it’s a bit crazy to run a pre-release version of a filesystem just to use a newer Kernel version, but that’s me, and everyone has different trade-offs for their use-cases.)

The use case here is usually something like

1. My <hardware> is essentially unusable on <current kernel>
2. My <hardware> isn't unusable on <latest kernel>
3. The comparative disadvantage is worthwhile to have usable <hardware>

For instance, the only reason I'm on unstable zfs is because the alternative is constant kernel panics from my graphics card... There really isn't an alternative.

[unhitched9271]

Personally, I think it’s a bit crazy to run a pre-release version of a filesystem just to use a newer Kernel version, but that’s me, and everyone has different trade-offs for their use-cases.)

The use case here is usually something like

1. My is essentially unusable on
2. My isn't unusable on
3. The comparative disadvantage is worthwhile to have usable

For instance, the only reason I'm on unstable zfs is because the alternative is constant kernel panics from my graphics card... There really isn't an alternative

This is also the case for me. I had 6.10 pinned as it had support for my hardware, and had an accompanying stable version of zfs. To standardize my configuration, the rest of my hosts had the same pairing.

However given the speed of the removal of 6.10 kernel from NixOS, I essentially overnight couldn't easily update software anymore, or build new hosts. I tried and failed understand how to create an overlay solely for the kernel and zfs, the motivation for one was so I could hang onto 6.10 until there was a new stable version of zfs available for the 6.11 kernel.

Therefore moving to 6.11 and the unstable version of zfs was the only achievable option for me in the short term.

This was my first experience of using new hardware which needed a newer kernel on NixOS, and having the ability to use the currently installed kernel being yanked overnight wasn't pleasant.
I appreciate the kernel is EOL... but wouldn't a warning be a more reasonable way of preventing this scenario from occuring?

I also appreciate ZFS likely isn't the most popular FS on NixOS - but surely warnings instead of force (and if not) a well documented workaround should be readily available so that people at least have the choice --->

Upgrade to current kernel + unstable zfs

OR

stay on the EOL kernel + stable zfs, until a new stable release of zfs is available.

[unhitched9271]

I'm not sure that my comment is in the "right" place, can anyone point me to the most appropriate place to chip in the above into the discussion? I can find multiple issues/PRs that relate to this in some way !

After the pointer I'll remove the above comment and this one