qt5-packages.nix: consistently make all libraries with same qt5 version

[FRidh]

Motivation for this change

Reduce the chance of mixing Qt versions by having Qt-based libraries in a separate package set.

Builds upon #101369.

Things done

• Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
• Built on platform(s)
  • NixOS
  • macOS
  • other Linux distributions
• Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
• Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
• Tested execution of all binary files (usually in ./result/bin/)
• Determined the impact on package closure size (by running nix path-info -S before and after)
• Ensured that relevant documentation is up to date
• Fits CONTRIBUTING.md.

To do

• move callPackage into qt-packages.nix
• consider WIP: treewide: splice more nested package sets #105374 for cross-compilation. I do think all the makeScope usage for Qt and such itself is going to make this difficult
• update docs
• rename libsForQt5

[doronbehar]

Long term thinking: How about changing a bit the attributes layout to look like this (json5):

qt5 = {
  // Same as today
  qtbase = ..
  // Other qt modules
  libraries = {
    // All what was previously in libsForQt5
  },
  apps = {
    // the apps from qt5-applications.nix
  }
}

And so on, with qt515 and qt514 etc.

[ttuegel]

How about changing a bit the attributes layout to look like this (json5):

qt5 = {
  // Same as today
  qtbase = ..
  // Other qt modules
  libraries = {
    // All what was previously in libsForQt5
  },
  apps = {
    // the apps from qt5-applications.nix
  }
}

And so on, with qt515 and qt514 etc.

I don't really like this beacuse, as you rightly pointed out, the distinction between "library" and "application" is flexible.

I suggest the following, which I think is the same as the situation for Python right now:

1. All packages that depend on Qt go into qt-packages.nix. Basically, taking these changes to the next level.
2. Packages in qt-packages.nix get their dependencies from that set first, so that they see a consistent set of dependencies.
3. In all-packages.nix, we have attributes for the entire qt-packages.nix set instantiated with different versions of Qt: qtPackages5_14, qtPackages5_15, etc. The default version will be qtPackages5 = qtPackages5_yy. Hydra will not recurse into these sets.
4. For stand-alone packages (that is: applications) add an attribute to all-packages.nix like konsole = qtPackages5.konsole. If the package needs to be pinned to a certain version of Qt, the maintainer can do that, too.

I think this would fix the mixed-version problems we have. The one problem: I don't know how to make this work with PyQt packages; they would somehow need to live in two package sets at once. I guess we can leave PyQt in pythonPackages (built with all versions of Python) and pin it to a particular version of Qt because all Python packages that depend on Qt should get it through PyQt so there is no risk of mixing versions.

[FRidh]

For clarity I've kept libsForQt5 for now. Once everything else is fine, we can do a simple replacement to the chosen name.

If what's here now is fine, I'll move over more callPackage lines into qt-packages.nix.

[FRidh]

If what's here now is fine, I'll move over more callPackage lines into qt-packages.nix.

Did not do this eventually and this is now a follow-up task. Resolved the merge conflicts and merged this to avoid getting more conflicts.

[SuperSandro2000]

This PR broke eval on staging because fcitx-qt5 is no longer available. 2e9c639#diff-ab5748dc9567516fefba8344056b51ec1866adeace380f46e58a7af3d619ea22L15904

[cole-h]

Rather, fcitx5-qt; #104658 and https://gist.github.com/8b2da452fad700c6e82220ae8039cca5.

EDIT: #108950 is where this cropped up.

[FRidh]

Thanks. Fixed with 05ca995.

[anund]

Is there an additional change to turn error: undefined variable 'kdeApplications' at ... into an informative message? Looks like the equivalent for kdeApplications.dolphin-plugins is now plasma5Packages.dolphin-plugins.

[anund]

or plasma5Packages.kdeApplications.dolphin-plugins.

[jorsn]

The one problem: I don't know how to make this work with PyQt packages; they would somehow need to live in two package sets at once. I guess we can leave PyQt in pythonPackages (built with all versions of Python) and pin it to a particular version of Qt because all Python packages that depend on Qt should get it through PyQt so there is no risk of mixing versions.
-- @ttuegel (#102168 (comment))

If you have scope A with subscopes B1, B2 and C and you want to change the version of B1 to B2 for use in C, you have to override B1 in A i.e. set A.C = (A.extend (self: super: { B1 = A.B2; })).C to avoid inconsistent versions at some level. So PyQt5 needs to be pinned to the same qt5 that the whole python closure uses. If python used another qt version than the tree-wide default this would probably lead to the same practically unmanageable mess we had in September (see #99956).