https://bugzilla.redhat.com/show_bug.cgi?id=1040517
--- Comment #70 from Paulo Andrade <paulo.cesar.pereira.de.andrade(a)gmail.com> ---
(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).
--
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