https://bugzilla.redhat.com/show_bug.cgi?id=1223673 --- Comment #8 from Jens Petersen <petersen@xxxxxxxxxx> --- (In reply to Milan Bouchet-Valat from comment #7) > the unversioned .so > files in the path, which is common with llvm and llvm34. I'm inclined to say > that's OK for now, and we should try to fix this in the llvm package first.. > It's not like we're introducing a new bug... Yeah, looking at it again further it does not seem that bad actually: /etc/ld.so.conf.d/llvm-x86_64.conf /usr/lib64/llvm/BugpointPasses.so /usr/lib64/llvm/LLVMgold.so /usr/lib64/llvm/libLLVM-3.5.0.so /usr/lib64/llvm/libLLVM-3.5.so /usr/lib64/llvm/libLTO.so /usr/lib64/llvm/readline.so LLVM.so is versioned (before .so) which I consider sufficient. Then there are a number of modules which I think are also okay (no idea what readline is doing there...). Which just leaves libLTO.so, which seems to me is not used by anything in llvm35? (Not sure what it is for to be honest.) So I also feel we could waive this like was done for llvm34. > - Minor point: I realized each subpackage creates its own directory > under /usr/share/doc/. Since they contain very few files and most apply > to all subpackages (e.g. LICENSE.txt), wouldn't it be better to put > everthing > under a common llvm dir? This is true and also true for many other packages I think. I'd rather just leave it for simplicity - though in principle I agree with you completely, but I feel this is more a deficiency of rpm. > [!]: Development (unversioned) .so files in -devel subpackage, if present. > Note: Unversioned so-files in private %_libdir subdirectory (see > attachment). Verify they are not in ld path. See above > [!]: Package must own all directories that it creates. > Note: Directories without known owners: /usr/lib64/llvm35 This is a fedora-review bug. > [!]: %build honors applicable compiler flags or justifies otherwise. > Could you add a comment explaining why %{optflags} is ignored > and why --with-optimize-option=-O3 is a good idea? Okay > [!]: Patches link to upstream bugs/comments/lists or are otherwise > justified. > Could use a bit more verbose comments and links to upstream patches. > Checking: llvm35-3.5.2-1.fc22.x86_64.rpm > llvm35-devel-3.5.2-1.fc22.x86_64.rpm > llvm35-doc-3.5.2-1.fc22.noarch.rpm > llvm35-libs-3.5.2-1.fc22.x86_64.rpm > llvm35-static-3.5.2-1.fc22.x86_64.rpm > llvm35-3.5.2-1.fc22.src.rpm > llvm35.x86_64: W: spelling-error %description -l en_US runtime -> run time, > run-time, rudiment > Could fix this one. Hmm, isn't "runtime" pretty standard? > llvm35.x86_64: W: no-manual-page-for-binary llvm-diff-3.5 : : > llvm35-devel.x86_64: W: no-manual-page-for-binary llvm-config-64-3.5 > Why don't we have manpages for all those commands, even in the standard llvm > package? Good question - perhaps Fedora could grab a patch from Debian? Again I think this should be done first for the llvm package. I opened bug 1258760 for that. > llvm35.src:177: E: hardcoded-library-path in > %{_prefix}/lib/gcc/%{_target_cpu}*/*/include) > Out of curiosity, why doesn't gcc install these files under %{_libdir}? Historical I think - it is using target arch dirs instead of multilib. -- 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