Peter Simons writes: > Hi Anthony, > > >> [What is] a concrete use case that works for you today but that > >> won't work after LTS-4 has been dropped? > > > > Someone who has a project that works with package versions in LTS-4, > > but hasn't yet been upgraded to LTS-5 or 6. They can simply refer to > > LTS-4 in their shell.nix for haskell packages. > > Oh, but you can absolutely do that! You can extend the set of available > packages to your heart's content and you can compose package sets that > provide any combination of versions as you please. The Haskell > infrastructure in Nix gives you that ability. > > > >>> You are removing that opportunity because it hasn't been used yet. > >> > >> I don't intend to remove any "opportunities" here. All I want to remove > >> is some 850,000 lines of untested, unmaintained code from the Nixpkgs > >> repository. [...] > > > > If it's 850,000 lines of code, then that really seems like a Nix > > issue. If the point here is to declare bankruptcy and tell people to > > use stack which is able to refer to multiple versions of packages, > > then let's call it that. > > I have a hard time assigning meaning to vague terms like "removing > opportunities" and "declaring bankruptcy" in a technical conversation. I > am sorry, I just don't see how to these kind of things make a compelling > argument for distributing old LTS releases in Nixpkgs.
I truly don't understand why this is hard for you to understand, so we are of a mind on this misunderstanding! There must be a language barrier or different understanding of what breaking version changes are between us. > > [A team using Nix today] can refer to LTS-5 in nixpkgs, and not need > > to make any changes to adopt LTS-6 until they are ready. I know that > > should a problem emerge with LTS-5, a project using stack has a good > > chance of benefiting from a new Stackage release. I know that after > > the changes you are making, the team using LTS-5 in nixpkgs will not > > have a working environment until they address any of the 5->6 > > breaking changes. > > This is true only if we assume that the team depending on LTS-5 updates > their copy of Nixpkgs to a version that breaks their code. But they > don't have to. They can use a version of Nixpkgs that works for them > until they're comfortable addressing the issues caused by an update. > Also, these changes I'll be making show up only in the branch we dub > "unstable". The release-16.03 branch, for example, has LTS-5 and will > continue to have it until all eternity. > > You realize that Nix allows you to override the contents of the Nixpkgs > version you're using without actually editing that version, right? You > can stick to any given version of Nixpkgs, but if an update of, say > libuuid, comes out that you'd like to have, then you can override only > that particular package in configuration.nix or ~/.nixpkgs/config.nix > without ever touching Nixpkgs itself. This gives you a stable package > plus selected, hand-picked updates. IMHO that is an awesome mechanism > for stable deployments. I think that telling users to stick to a single version of nixpkgs and take responsibility for cherry-picking individual security and bug fix commits to all Haskell and system libraries they depend on is the worst job a package management system can do while still calling itself a package manager. I do appreciate that you find such a setup appealing, so I'll say no more as this is solely your call. Anthony _______________________________________________ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev