| 21 Nov 2025 |
| jopejoe1 (4094@39c3) joined the room. | 13:58:56 |
| 24 Nov 2025 |
| @whispers:catgirl.cloud joined the room. | 00:28:09 |
| @whispers:catgirl.cloud left the room. | 02:25:45 |
| Grimmauld (any/all) joined the room. | 12:45:57 |
| 28 Nov 2025 |
| Grimmauld (any/all) changed their display name from grimmauld (any/all) to musl-official | Grimm | any/all. | 11:35:38 |
| Grimmauld (any/all) changed their display name from musl-official | Grimm | any/all to Grimmauld (any/all). | 11:36:00 |
| 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 |