Created attachment 1130856 [details] Patch to the spec file Description of problem: Broken links to libraries from other packages: libcholmod, libgit2, and libfftw3_threads Version-Release number of selected component (if applicable): julia-0.4.3-1.fc23.x86_64 How reproducible: Always Steps to Reproduce: 1. ls -l /usr/lib64/julia/ 2. 3. Actual results: Shows broken links for the above mentioned libraries Expected results: Functioning links to the above mentioned libraries Additional info: I have attached a patch to the spec file with the bug report.
Thanks. This is really silly as I had fixed this in the Copr, but for some reason I forgot to apply the patch in the official repos too. We should really find a more robust solution, which would trigger an error when a link gets out of date. I've just pushed your fix to F23, F24 and rawhide. I'll request updates as soon as the builds complete.
julia-0.4.3-2.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2016-14bc22384b
I have an idea, but maybe it is ugly. What about requiring the devel packages as a requirement? Then you can link to the unversioned libraries in libdir/julia. R requires quite a few indirectly, so there is precedence. Take a look at this: $ for p in R{,{,-core}-devel}; do rpm -q --requires $p; echo END; done | grep -e devel -e END R-devel = 3.2.3-2.fc23 libRmath-devel = 3.2.3-2.fc23 END R-core-devel = 3.2.3-2.fc23 R-java-devel = 3.2.3-2.fc23 END blas-devel >= 3.0 bzip2-devel lapack-devel libX11-devel libicu-devel pcre-devel tcl-devel tk-devel tre-devel xz-devel zlib-devel END However the proper question is, why does Julia need external libs in libdir/julia? It should be able to find them from the usual location like all other programs do. Maybe this should be reported upstream?
Depending on -devel packages isn't great as it pulls many unneeded files and these packages are not parallel-installable with other versions of the same library. We've been discussing what the best solution is upstream: https://github.com/JuliaLang/julia/issues/6742 A good fix would be to generate Requires for a specific version, so that we know when to rebuild the package and update the symlink.
Created attachment 1130889 [details] Example spec file patch I did say the idea was ugly :-p. If you prefer explicit requires in the spec file, how about something like the attached diff? I considered only libgit2 for the example.
Well, we can't depend on a specific version of a package, only on a SONAME: else, it would break too often for no good reason. Unfortunately, this cannot be done manually in the .spec file AFAIK. We've discussed how to do that with a dependency generator, but it doesn't look like it's possible without having another separate package just to generate the Requires. Ah, well...
You could depend explicitly on the path: Requires: /usr/lib64/libgit2.so.21
And you tell me this only now! :-) It's weird that we can't simply give the library SONAME, but indeed requiring a path to the file sounds like a great solution. I'll experiment with that ASAP.
Well, in general I don't like file path requires, because in the yum days that would trigger the download of the full filelists metadata which is big. But apparently dnf at the moment downloads it all the time now. You could instead list the proper soname (e.g. Requires: libgit2.so.21()(64bit)) but the trick is generating that automatically.
Actually, it appears that if I include the symlinks in the package, instead of generating them in %post (as you advised some time ago), find-requires automatically adds the SONAME dependencies. I couldn't find any documentation explaining how this works, but... So in the end it looks like we have a great solution: create symlinks pointing to whatever the unversioned .so symlink points to. That way, a simple rebuild is enough when a dependency changes SONAME (assuming that the tests keep passing), but the binary package declares the correct Requires. I think I'm going to commit this, unless you find a clear drawback to it: pushd %{buildroot}%{_libdir}/julia ln -sf $(readlink -f %{_libdir}/libarpack.so) libarpack.so ln -sf $(readlink -f %{_libdir}/libcholmod.so) libcholmod.so ln -sf $(readlink -f %{_libdir}/libdSFMT.so) libdSFMT.so ln -sf $(readlink -f %{_libdir}/libgit2.so) libgit2.so ln -sf $(readlink -f %{_libdir}/libfftw3.so) libfftw3.so ln -sf $(readlink -f %{_libdir}/libgmp.so) libgmp.so ln -sf $(readlink -f %{_libdir}/libmpfr.so) libmpfr.so %ifarch %{ix86} x86_64 ln -sf $(readlink -f %{_libdir}/libopenlibm.so) libopenlibm.so %endif ln -sf $(readlink -f %{_libdir}/libopenspecfun.so) libopenspecfun.so ln -sf $(readlink -f %{_libdir}/libpcre2.so) libpcre2.so ln -sf $(readlink -f %{_libdir}/libumfpack.so) libumfpack.so popd
Ah, and the link to the Koji build with this code: http://koji.fedoraproject.org/koji/taskinfo?taskID=13141884
Actually, realpath is better than readlink as it will fail when the file does not exist, while the code I posted above silently creates a symlink pointing to itself.
julia-0.4.3-2.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-14bc22384b
Orion, do you think I can commit this?
yes, looks good to me.
Thanks, I've pushed that change.
julia-0.4.3-2.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.