You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm hunting down usages of multiple versions of the same library in the packages that I use. So for example, a week ago or so, I discovered that frei0r, is built with opencv2 while the latest opencv4 is also supported. Unfortunately, this pattern is a bit common in Nixpkgs (Ahm Python) and the downside of it is that it can increase closure size if you have certain packages installed at the same time. For example, frei0r is a dependency of ffmpeg, and opencv4 is a dependency of some gst-plugins. This means that if you have them both installed, you get two different opencv derivations in your store but it doesn't have to be that way.
After reaching for feedback on discourse I learned that our policy regarding this should be to make libfoo point to the latest libfoo, and not to libfoo2 if there's e.g a libfoo3 available.
I've had a successful "sprint PR" for making opencv point to the latest version at #86808 and I tested that all of the dependent packages were still building with the newer opencv.
"Renaming" llvm to point to llvm_latest cannot be covered in a single PR like with opencv, so I'm hunting down packages 1 by 1. The biggest bite is for rustc:
FWIW, upstream is currently using LLVM 9. Their PR to switch to 10 (rust-lang/rust#67759) was opened on Dec 31 and looks like it's getting close to merging now. That 4.5-month delay seems like a pretty good sign that immediately switching to new LLVMs is likely to cause regressions, so maybe best to wait?
It's worse on Darwin, by the way, where rustc alone requires LLVM 5 (see #87443), two copies of LLVM 7 (blame stdenv, see #87583), and LLVM 9.
Thanks for the quick reply :). rust-lang/rust#67759 is the answer to my question - it certainly won't worth the risk. I've subscribed to that issue and I hope I'll remember after it'll merge to make sure our rustc is using llvm_latest or llvm_10.
I'm hunting down usages of multiple versions of the same library in the packages that I use. So for example, a week ago or so, I discovered that
frei0r
, is built with opencv2 while the latest opencv4 is also supported. Unfortunately, this pattern is a bit common in Nixpkgs (Ahm Python) and the downside of it is that it can increase closure size if you have certain packages installed at the same time. For example,frei0r
is a dependency offfmpeg
, andopencv4
is a dependency of somegst-plugins
. This means that if you have them both installed, you get two differentopencv
derivations in your store but it doesn't have to be that way.After reaching for feedback on discourse I learned that our policy regarding this should be to make
libfoo
point to the latestlibfoo
, and not tolibfoo2
if there's e.g alibfoo3
available.I've had a successful "sprint PR" for making
opencv
point to the latest version at #86808 and I tested that all of the dependent packages were still building with the newer opencv."Renaming"
llvm
to point tollvm_latest
cannot be covered in a single PR like with opencv, so I'm hunting down packages 1 by 1. The biggest bite is forrustc
:nixpkgs/pkgs/development/compilers/rust/rustc.nix
Line 3 in 39b92f6
I hope it's OK to ask here the maintainers - @madjar, @cstrahan, @globin, @Havvy : Is there a particular reason that you chose to use
llvm_9
and notllvm_latest
? It seems upstram doesn't have any constraint on that, according to: https://rustc-dev-guide.rust-lang.org/building/suggested.html#building-with-system-llvmAnd, it seems that even
@rust-lang
's fork of llvm is also updated against the current latest llvm which is 10 according to: https://github.com/rust-lang/llvm-project/tree/rustc/10.0-2020-05-05The text was updated successfully, but these errors were encountered: