https://bugzilla.redhat.com/show_bug.cgi?id=1040517 --- Comment #68 from Paulo Andrade <paulo.cesar.pereira.de.andrade@xxxxxxxxx> --- 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 _______________________________________________ package-review mailing list package-review@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/package-review