qgis: 3.16.13 -> 3.16.14

[lsix]

Motivation for this change

Update to latest LTS.

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 21.11 Release Notes (or backporting 21.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
  • (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes
• Fits CONTRIBUTING.md.

[erictapen]

@lsix In the meantime, 3.22.1 was released. Could you bump to that?

[sikmir]

@lsix In the meantime, 3.22.1 was released. Could you bump to that?

3.22.1 is not LTR. But it would be good to have both versions: LTR and current.

[erictapen]

Oops, could have guessed that from when 3.22.1 came out. Is there any particular reasoning behind only packaging the LTS release here? As a user I'd expect the qgis attribute to be the latest release, while something like qgis-lts could point to the LTS release.

[sikmir]

Is there any particular reasoning behind only packaging the LTS release here?

I guess there is no reason, I'll try to build 3.22.1.

As a user I'd expect the qgis attribute to be the latest release, while something like qgis-lts could point to the LTS release.

Agree.

[erictapen]

Btw would be interested in being a maintainer to qgis, so could you add me to maintainers if you prepare a bump anyway?

[lsix]

@erictapen if you wand to join and help maintain QGIS in nixpkgs, maybe you can create I PR adding yourself in the maintainers list? I’ll happily approve that! This would have to be in a separate commit from the bump anyway.

On the subject of LTS v.s. non LTS, as NixOS is a non rolling release, I have always found it easier to maintain LTS versions of packages. Otherwise backport to release branches can be a pain as it can imply backporting dependencies to new versions which can have bigger impacts than just upgrading qgis. This i has be especially true when migrating from QGIS-2 to QGIS-3. And to be fair, at that time, just having QGIS-2 (LTS) and QGIS-3 (latest) in tree would have be quite a pain. As of now, the dependencies are much closer than what they used to be at that moment, but I kept this habit of only maintaining QGIS-LTS.

Apart from that, and as far as I am aware, there is no strong reason that prevents us from having both a latest and a lts version available. Hopefully, we fill not see to much situations where the two versions require incompatible dependencies.

[erictapen]

I see your point here about the ease of backporting changes to LTS releases. Still there are the unstable channels that always benefit of having the newest version. Also NixOS somewhat has a reputation for always having the newest package version available (see e.g. Newest metric on repology).

Do I understand it right that you would be in favor of maintaining both LTS and latest qgis? If yes, I'd propose to name them qgis-lts and qgis, as that seems to be a common scheme in Nixpkgs.

[erictapen]

Almost forgot: Builds for me!

[willcohen]

a vote in favor of qgis-ltr and qgis!

particularly re #71398, i can imagine that at different times trying to keep darwin compatibility working might be better or worse in either of the two packages. on the one hand, once it's built, ltr would seem to be a more stable target. on the other hand, as was/is true with PyQt5 on darwin (for homebrew in addition to nix), it may end up that targeting more modern builds might help keep one of the two formulas working if the old versions of Qt or other dependencies make ltr more brittle the more long in the tooth it gets.

[bobby285271]

Trusting existing reviews and I guess this is ready to merge.