https://bugzilla.redhat.com/show_bug.cgi?id=1040517 --- Comment #65 from Paulo Andrade <paulo.cesar.pereira.de.andrade@xxxxxxxxx> --- > > 1) I believe none of the installed Makefile files are required > > (or functional): > > $ find /usr/share/julia/ -name Makefile > > /usr/share/julia/test/perf/micro/Makefile > > /usr/share/julia/test/perf/shootout/Makefile > > /usr/share/julia/test/perf/Makefile > > /usr/share/julia/test/Makefile > > /usr/share/julia/examples/Makefile > Right, these only work from inside the source tree anyway. I've even removed > the perf suite, which does not work when installed, and contains a few files > with non-MIT licenses. %check now fails like this: exception on 1: ERROR: opening file perf/kernel/imdb-1.tsv: No such file or directory in open at ./iostream.jl:117 in open at ./iostream.jl:135 while loading readdlm.jl, in expression starting on line 4 ERROR: opening file perf/kernel/imdb-1.tsv: No such file or directory in open at ./iostream.jl:117 in open at ./iostream.jl:135 while loading readdlm.jl, in expression starting on line 4 while loading /home/pcpa/rpmbuild/BUILD/julia-0.3.0/test/runtests.jl, in expression starting on line 35 Makefile:16: recipe for target 'readdlm' failed make: *** [readdlm] Error 1 > > 2) Is it really required to install /usr/share/julia/test ? > > I checked it, and apparently must call the runtests.jl, I > > did not change the environment, but apparently not everything > > was fine: > [...] > Yeah, currently the backtrace test is failing with LLVM 3.4 > (https://github.com/JuliaLang/julia/issues/8099). I think it's still better > to ship this file, hopefully this will get fixed soon enough. (FWIW, this > file can be called by Base.runtests().) > > > 3) Can it be changed to install documentation in %_docdir? > > All documentation is under /usr/share/julia > Yes, I've filed a bug upstream, and for now I move the files manually: > https://github.com/JuliaLang/julia/issues/8367 Looks almost good :) Just that now there are two packages owning LICENSE.md and other UPPERCASE files. BTW, you could change: %files doc %dir %{_docdir}/julia/ %doc %{_docdir}/julia/* to %files doc %doc %{_docdir}/julia/ > > 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. > > 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. 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. 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. 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. -- 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