lixPackageSets.lix_2_9{0,1}: drop #426260
Conversation
| # Note: This is not yet 2.92 because of a non-deterministic `curl` error. | ||
| # See: https://git.lix.systems/lix-project/lix/issues/662 | ||
| stable = self.lix_2_91; | ||
| stable = self.lix_2_92; |
There was a problem hiding this comment.
I don't think this is a good idea. 2.92 contains a known deadlock during substitution and I don't think there is any reason at all to use it over 2.93.
There was a problem hiding this comment.
Fine by me, in that case, we should probably consider pruning 2.92 as well.
|
There are quite a few conditionals for older versions in common-lix.nix which could be removed along with the old versions. Similar for the nix-eval-jobs source which can always be assumed to be the same as lix if you end up dropping everything below 2.93. |
|
I didn't drop them on purpose to let users reintroduce those versions
without breaking the build code, on the next release, I'd drop them.
Le ven. 18 juil. 2025, 17:16, alois31 ***@***.***> a écrit :
… *alois31* left a comment (NixOS/nixpkgs#426260)
<#426260 (comment)>
There are quite a few conditionals for older versions in common-lix.nix
<https://github.com/NixOS/nixpkgs/blob/c4ea7e484bd1de914d3b75481d6457bb06c6144e/pkgs/tools/package-management/lix/common-lix.nix>
which could be removed along with the old versions. Similar for the
nix-eval-jobs source which can always be assumed to be the same as lix if
you end up dropping everything below 2.93.
—
Reply to this email directly, view it on GitHub
<#426260 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AACMZRGE7Z6RETM3LVL5MZL3JEFT3AVCNFSM6AAAAACBZNX7TOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTAOBZHAZDAOJVGY>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
859614d to
045b6e3
Compare
Lix 2.90 is vulnerable to critical CVEs, known vulnerabilities warnings were emitted. Users should have migrated by then. There's no reason to keep it in-tree anymore. Change-Id: I631b234346a2c687e23b5f5de97674ec2214111d Signed-off-by: Raito Bezarius <masterancpp@gmail.com>
045b6e3 to
f2a15a7
Compare
Lix 2.91 has been one of our historical LTS releases given that the Lix 2.92 series suffered from an unfortunate curl upstream bug and it took a lot of time to fix it, in addition of other papercuts with SSH connections. Lix 2.91 is the last release not containing the asyncification work we started. Lix 2.92 latest minors sorted out these issues and possess bits of asyncification, it's a much easier target for HEAD cherry-picks because it also renamed the directory `src/nix` to `lix/`. Plans are the following: * Lix 2.92 is skipped. * Lix 2.93 is the new stable. * Lix 2.94 is the next stable. Once NixOS 25.11 releases, Lix 2.92 will be dropped. Lix 2.92 suffers from slight performance issues that are made up in Lix 2.93, your mileage may vary. Change-Id: I83d0d1764edfc4009e4373f6b22d728390419e30 Signed-off-by: Raito Bezarius <masterancpp@gmail.com>
f2a15a7 to
61de286
Compare
|
After the discussion in #433057, I believe we should not drop Lix 2.91, yet, at least from a Nixpkgs perspective. Imho, this should only happen in 26.05, not in 25.11. We don't have a formal policy for this, yet, but I think it's reasonable to expect to be able to update from NixOS 24.11 to NixOS 25.11, because they overlap: There is a period where NixOS 24.11 is still supported and NixOS 25.11 is already being developed. To be able to verify that NixOS 25.11 evaluates with a NixOS 24.11 running Lix, we need to have Lix 2.91 still available in NixOS 25.11 - that's the reasonable amount of effort we can take to run it in CI etc. Since 24.11 was on 2.91 by default, and also doesn't have any newer Lix version, it would help to keep 2.91 until 26.05 branch-off. Of course, this only makes sense if it's also still supported upstream and doesn't become insecure. I think the fact that 2.91 is still the default in NixOS 25.05 is another argument for it. cc @emilazy (Edit: Note, this is intended to start the discussion about such a policy - how long should we expect Lix versions from one release to be in following releases? I said two cycles, the general answer could also be one cycle only, ofc) |
To make some concrete proposals: 1. Default +2 Each NixOS release's default Consequences (assuming 2.93 becomes the default in 25.11):
2. Latest +2 Each NixOS release's Consequences:
3. Default +1 Each NixOS release's default Consequences:
4. Latest +1 Each NixOS release's Consequences:
This PR, dropping 2.91 right now, would be at the bottom of this list in "Latest +1". I think that might not be enough. My proposal above is "Latest +2", I think. Maybe both of "Latest +2" and "Default +1"? |
|
I think it's more important to base our deprecations on what was stable. Doing a quick Github search, there are currently 476 uses of I don't want to state specific support windows, because I think that's up to the Lix team. My core opinions are:
Personally, I don't think 2.91 should be removed entirely yet. I'd prefer a deprecation warning for a single release, which reflects that it's only receiving security patches. |
|
Ideologically:
So far in Lix development, we've not really had a release that had significant unknown defects in it upon release since we have pretty strong QA on the main branch. Maybe we can keep stable-1 around with minimal maintenance in case something gets really blown up, but backporting further than the current stable means any of those old stable releases do not receive any meaningful QA. |
|
(What macOS kernel bug, btw?) |
OK, so let's assume that latest Lix is always backported and becomes the new
Yeah, if that's only ever going to be an unintended thing, then +1 should be enough. Just to make sure we can verify Nixpkgs still evaluating properly for those who are not on the latest stable NixOS version, yet. In practical consequences this means:
This means Lix 2.91 would still have to be supported until November. At least basic support as in: If there is anything security critical coming up, this would be fixed, so that the package doesn't need to be marked insecure. Does that make sense? |
|
Given that I have been in charge of the previous security issues, I think it's plausible we can do security until November but 2.91 is a highly expensive release, so November ought to be the utmost maximum support in nixpkgs IMHO. |
Lix 2.90 series
Lix 2.90 is vulnerable to critical CVEs, known vulnerabilities warnings
were emitted. Users should have migrated by then.
There's no reason to keep it in-tree anymore.
Lix 2.91 series
Lix 2.91 has been one of our historical LTS releases given that the Lix
2.92 series suffered from an unfortunate curl upstream bug and it took a
lot of time to fix it, in addition of other papercuts with SSH
connections.
Lix 2.91 is the last release not containing the asyncification work we
started.
Lix 2.92 latest minors sorted out these issues and possess bits of
asyncification, it's a much easier target for HEAD cherry-picks because
it also renamed the directory
src/nixtolix/.Plans are the following:
Once NixOS 25.11 releases, Lix 2.92 will be dropped.
Lix 2.92 suffers from slight performance issues that are made up in Lix
2.93, your mileage may vary.
Things done
nix.conf? (See Nix manual)sandbox = relaxedsandbox = truenix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage./result/bin/)Add a 👍 reaction to pull requests you find important.