https://bugzilla.redhat.com/show_bug.cgi?id=1040517 --- Comment #70 from Paulo Andrade <paulo.cesar.pereira.de.andrade@xxxxxxxxx> --- (In reply to Milan Bouchet-Valat from comment #69) > (In reply to Paulo Andrade from comment #68) > > You probably saw I posted to devel@ earlier today about issues > > with rpath/runpath. I was waiting for some comment on that > > before replying, but none so far... > You're probably aware of this, but there are two points in the rpmlint wiki > page: > http://fedoraproject.org/wiki/Packaging:Guidelines#Beware_of_Rpath > > The second one, "Rpath for Internal Libraries", seems to apply to us. In the (recent) past rpmbuild would fail in these cases. I have packages were I added a wrapper setting LD_LIBRARY_PATH, or if the library is not "truly" private, install /etc/ld.so.conf.d/$name-$arch.conf Currently it is apparently only causing a rpmlint error. But unless with more feedback, I will *not* consider it mandatory to remove rpath to get the package approved, because it pass build and there are a lot of binaries in rawhide, several with a bogus one, rpath/runpath. > [...] > > > Yes, copying these files from Julia git seems to work, but then I need to > > > carry the patch and move files around by hand. Is it really worth it? I'd > > > prefer fixing this upstream directly, I've filed an issue: > > > https://github.com/JuliaLang/julia/issues/8378 > > > > I asked it because I know it should be easy, and would greatly increase > > the quality of the package, and/or, it could detect problems in the > > documentation itself. While waiting for upstream, please make a > > simple patch to get html documentation built. You will make the > > reviewer a lot happier :) > OK, done. :-) At first I only suggest this pseudo patch to the spec: -rm -R %{buildroot}%{_docdir}/julia/html/_sources Because there is that "big" "View page source" on every documentation page, that just leads to a page like this: " File not found Firefox can't find the file at /usr/share/doc/julia/html/_sources/index.txt. Check the file name for capitalization or other typing errors. Check to see if the file was moved, renamed or deleted. " > [..] > > > > It would be better to not make the libjulia.so symlink to start with. > > > I don't think so, as GUIs embedding Julia, like iJulia, may need to link to > > > it. I realize this may be an argument in favor of adding a SOVERSION. I > > > guess I should ask upstream about that. > Actually, I'm starting to think I should stop installing libjulia.so to > /usr/lib64, as this is not done by default by Julia, and there's the > SOVERSION issue. So for now I've removed it, and we'll see if something like > iJulia needs it later. > > [...] > > AFAIK what should work is to check what "rpm -q --requires dSFMT-devel" > > outputs and add that, but it would change from arch to arch, and is an > > ugly and fragile hack, e.g. on x86_64: > > > > Requires: libdSFMT.so.2.2()(64bit) > Ah, it's unfortunate. That would have been the best solution to handle > dlopen()ed dependencies in the long term. > > > Anyway, in case it may be helpful, this is how I avoid rpmlint > > warnings on dangling symlinks in sagemath: > > http://pkgs.fedoraproject.org/cgit/sagemath.git/tree/sagemath.spec#n1102 > > you could write something like this in %post: > > ln -sf /usr/lib64/libdSFMT.so.2 /usr/lib64/julia/libdSFMT.so > OK, done. But now rpmlint grants me with a > julia.x86_64: W: dangerous-command-in-%post ln > julia.x86_64: W: dangerous-command-in-%postun rm I believe these can be ignored, as the end effect of not needing to install -devel packages should be better. But, can you provide a simple test case to exercise the julia interface to dlopen those? Just to make sure it works with only /usr/lib64/julia/libdSFMT.so that is, will not fail if /usr/lib64/libdSFMT.so is not available (as well as the other links). > New version: > Spec URL: http://nalimilan.perso.neuf.fr/transfert/julia.spec > SRPM URL: http://nalimilan.perso.neuf.fr/transfert/julia-0.3.0-5.src.rpm -- You are receiving this mail because: You are on the CC list for the bug. You are always notified about changes to this product and component _______________________________________________ package-review mailing list package-review@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/package-review