Nixpkgs' policy regarding libraries available in multiple versions

Development
1

So today I did some clean up to my /nix/store, by inspecting all directories there and sorting them according to disk usage.

I'm using this command BTW. 
du -csh /nix/store/* | sort -rh | fzf --preview-window=down --preview='pistol {2}; printf "\n\n\n%s\n\n" "@@@ $(du -sh {2}) @@@"; printf "\n\n\n%s\n\n" "@@@ referrers @@@"; nix-store -q --referrers {2}; printf "\n\n%s\n\n" "@@@ references @@@"; nix-store -q --references {2}' | awk '{print $2}'

Anyway, I noticed I have both opencv2 and opencv4 installed. opencv4 is needed for gst plugins and opencv2 is needed only by frie0r-plugins (mpv dependency). I tested the build of frei0r with opencv4 instead of opencv2 and it worked, so I assume it’s potentially possible to change this and make sure all of the reverse dependencies of frei0r work.

Besides opencv, I noticed I have two version of some LLVM packages because of a similar reason, only different packages.

Hence I wonder, should we always test packages builds with the latest versions of such libraries? Theoretically, it’s not necessarily benefitial for closure size decrease for everyone, as it could be that someone else would have a package installed that works only with opencv2, meaning changing this will increase his closure…

Perhaps a contra argument to the above, is that enforcing this policy will make users of such packages (which compile e.g with only opencv2) aware of this issue and direct it upstream…

1 Like
2

We aim to minimize the number of different versions using preferable the latest version of a library.
If you identify a package that can be compiled with a newer version you can make a pull request.
We also try to keep the default attribute pointed to the lastest version. This is however a significant amount of work for popular packages, which is why we might lack behind in this case.

4 Likes
3

I would suggest the following:

diff --git a/pkgs/top-level/all-packages.nix b/pkgs/top-level/all-packages.nix
index 178ee548545..9833a94cbdb 100644
--- a/pkgs/top-level/all-packages.nix
+++ b/pkgs/top-level/all-packages.nix
@@ -13804,7 +13804,7 @@ in
 
   openct = callPackage ../development/libraries/openct { };
 
-  opencv = callPackage ../development/libraries/opencv {
+  opencv2 = callPackage ../development/libraries/opencv {
     inherit (darwin.apple_sdk.frameworks) Cocoa QTKit;
   };
 
@@ -13820,6 +13820,8 @@ in
     inherit (darwin.apple_sdk.frameworks) AVFoundation Cocoa VideoDecodeAcceleration;
   };
 
+  opencv = opencv4;
+
   openexr = callPackage ../development/libraries/openexr { };
 
   openexrid-unstable = callPackage ../development/libraries/openexrid-unstable { };

This requires some testing. Some packages may need older opencv versions.

4

For anyone interested, there have been some progress on this topic. As a start:

https://github.com/NixOS/nixpkgs/pull/88714

Is a baby step towards an openjdk rename, should be OK. Renames jdk to point to jdk14, while every derivation that uses jdk without an explicit version suffix, now uses jdk8 explicitly, in order to avoid mass rebuilds and to make the review easier - by relying on the fact that no attributes were really affected.

This one:

https://github.com/NixOS/nixpkgs/pull/87848

Is specific for llvm - just a single package that starts to use now the latest version of llvm (if possible, for darwin that wasn’t possible).

There’s also:

https://github.com/NixOS/nixpkgs/pull/88195

Which renames libressl. Using ofborg I’ve checked there that nothing brakes so I think it’s good to go.