https://bugzilla.redhat.com/show_bug.cgi?id=1040517
--- Comment #68 from Paulo Andrade <paulo.cesar.pereira.de.andrade(a)gmail.com> ---
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...
> > > 1) I believe none of the installed Makefile files are
required
> > > (or functional):
[...]
So let's keep installing the perf suite for now, only removing
Makefiles.
> > > 2) Is it really required to install
/usr/share/julia/test ?
[...]
Ah, I've added a series of %exclude for -doc.
> > > 4) I believe there is something wrong with the
documentation. It
> > > should install processed documentation. I try to build it
> > > manually, by switching to the doc subdir I see this:
> > [...]
> > > So, I believe just the hack to create juliadoc/juliadoc/__init__.py is
not
> > > enough.
> > Yes, I've filed this in the same upstream issue. I'd say for now
let's
> > install the .rst files, which are readable if not pretty, and wait for
> > upstream to make it possible to install HTML files properly.
>
> I believe it can be fixed in the current rpm, probably a patch actually
> creating an usable juliadoc/juliadoc/__init__.py or whatever is
> missing from the tarball.
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 :)
> > > 5) It has been commented before, but it really would
be better to
> > > have a versioned .so under %_libdir; subdirectories usually are
> > > modules, and, usually are ok.
> > The problem is, Julia has not yet committed to API stability, so there's
no
> > versioning upstream, and if I invented one I would need to change the
> > SOVERSION for every new release. I'm not sure it's worth it. What do
you
> > think?
>
> 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.
> Then, remove the rpath from binary(ies) and add to the package
> an /etc/ld.so.conf/julia-%{_arch}.conf that on x86_64 would have
> /usr/lib64/julia
> as contents.
> Not the most "beautiful" way (better to patch build), but using
> "chrpath -d" after build should be ok to remove the rpath.
Actually the RPATH points to /usr/bin/../lib64/julia/, so I could remove the
symlink without problems for Julia itself.
> I believe, to remove another "rpmlint E:" you could instead of
> Requires: dSFMT-devel
> have a dangling link, e.g.:
> /usr/lib64/julia/lib.dSFMT.so -> /usr/lib64/libdSFMT.so.2
> or create it in %post (and remove in %postun) to avoid rpmlint
> warnings. This way it wold also break "on purpose" if there is
> a major bump of dSFMT.
Probably, but it sounds a bit hack (and I have to do the same for openlibm
and openspecfun). Isn't there any way of setting Requires(libdSMFT.so.2)?
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)
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
> Another issue is that you could split the files installed under
> /usr/share/julia in a noarch package, unless they are not noarch,
> but then they are in the wrong place :) Say, a new julia-data
> package or package similar name.
Done.
--
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