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…
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.
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.