| 29 Nov 2025 |
|  hab25 joined the room. | 16:33:35 |
| hab25 | Per my observation 1 year ago, the overwhelming majority of packages didn't get fixes backported into the nixpkgs-${currentReleaseNumber} branch. So my guess was that preferring nixpkgs-unstable for non-"system-level" packages (e.g., not systemd or gnome) counter-intuitively resulted in a more stable user experience.
I'm wondering if this still the case, so let's say I'm stating this conclusion but with regards to the present; any agreers/disagreers? Rationale very welcome.
| 16:36:43 |
 Alyssa Ross | I think you are correct and "unstable" should be renamed to "rolling". | 16:38:08 |
| hab25 | Thank you, that makes sense | 16:52:01 |
| hab25 | I'm getting the sense that the stable large channel should not exist, and the stable small channel should contain only these "system-level" packages | 16:52:53 |
| hab25 | And that this recommendation https://wiki.nixos.org/wiki/Channel_branches#When_unstable_lags_behind_master:~:text=For%20most%20users%2C%20a%20stable/large%20channel%20is%20recommended. should be changed | 16:53:05 |
| hab25 | Not only would this help users by eliminating the possibility of them making a bad choice, it would likely also lower maintenance efforts by getting rid of a branch (a large one, at that) | 16:54:06 |
 K900 | The "small" channels aren't a separate small subset of nixpkgs | 16:54:28 |
| K900 | And no, we can't drop the stable branches | 16:54:43 |
| K900 | People are relying on those | 16:54:48 |
| hab25 | the wiki I just linked says "a defined set of commonly-used packages" | 16:55:16 |
| K900 | And no, you can't generally mix random channels together and expect things to work, never mind be "more stable" than either channel by itself | 16:55:29 |
| K900 | The wiki is full of shit, as it often is | 16:55:36 |
 Grimmauld (any/all) | well, yes, but the derivations are exactly the same as in big channels, they aren't built twice like stable/unstable are built seperately | 16:55:55 |
| Grimmauld (any/all) | its not technically wrong, but it is misleading | 16:56:06 |
| Grimmauld (any/all) | And mixing channels is a very bad idea. For some pieces of software it works. But it gets notoriously finicky e.g. with graphics drivers being mismatched just to name one example | 16:57:59 |
| hab25 | Thanks, that makes sense | 16:58:57 |
| Grimmauld (any/all) | like, i can run firefox from stable 25.05 on unstable, but it doesn't have hardware accel. It is to be expected the other way round breaks similarly. I wouldn't call that stable and production ready. | 16:59:03 |
| K900 | I would add that the "stable base + unstable packages" setup would still have to be maintained | 16:59:33 |
| K900 | If we want it to be a thing we recommend to people | 16:59:39 |
| K900 | So there would need to be testing of it, etc, and at this point you've just reinvented the stable branch but more pain | 17:00:00 |
| Grimmauld (any/all) | this, and drawing a line becomes incredibly hard. | 17:00:07 |
| hab25 | I learned a lot, thank you all | 17:01:28 |
| Grimmauld (any/all) | Like, is muttersomething you'd pull from unstable? it has only 25 reverse dependencies. But you can't update mutter without updating glib, and glib is a mass rebuild. Would glib be from stable? Would that mean mutter needs to come from stable too? | 17:01:37 |
| Grimmauld (any/all) | it just doesn't work | 17:01:42 |
| Grimmauld (any/all) | i'd be on board with renaming unstable -> rolling, but thats about it. | 17:02:46 |
| hab25 | I'm thinking I'll prefer nixos-unstable then. I expect it won't cause me too much trouble given properly-locked nix makes things so easy to rollback | 17:05:04 |
 hexa | so staging -> stumbling -> rolling | 17:05:19 |
| hexa | * so staging -> stumbling -> rolling | 17:05:23 |
| K900 | Generally I'd argue that nixos-unstable should be your "default choice" | 17:06:08 |
