https://bugzilla.redhat.com/show_bug.cgi?id=1040517



--- Comment #72 from Paulo Andrade <paulo.cesar.pereira.de.andr...@gmail.com> 
---
(In reply to Milan Bouchet-Valat from comment #71)
> (In reply to Paulo Andrade from comment #70)
> >   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.
> > "
> Good catch. I'll fix that.
> 
> > > 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).
> The test suite already checks that AFAIK. But then I guess it's run when
> dSFMT-devel is still installed, as it's the build environment. What exactly
> do you have in mind?

I was thinking about some script to test it, after install, and only
be used during package review. But I tested it the "hard" way anyway;
I checked that the only one julia does not output some error/warning
message at startup is if there is a missing
%_libdir/julia/libopenspecfun.so so, it apparently always dlopen
libdSFMT.so and libopenlibm.so and either does not dlopen or does not
print anything if libopenspecfun.so is missing at startup.

Another minor cosmetic issue is that you are using %_datarootdir but
has one use of %_datadir; for consistency could change the later
to %_datarootdir in %files.

Otherwise, I believe it is almost done now :)

-- 
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@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/package-review

Reply via email to