https://bugzilla.redhat.com/show_bug.cgi?id=1474033 --- Comment #25 from Michal Schmidt <mschmidt@xxxxxxxxxx> --- (In reply to Andrey Maslennikov from comment #23) > >> %{_datadir}/doc/ucx > > Did you intentionally avoid using %{_pkgdocdir}? Is it because older distros do not define the macro? You could do what some other Fedora packages did for compatibility with EPEL 6: > > %{!?_pkgdocdir: %global _pkgdocdir %{_docdir}/%{name}-%{version}} > Yes, I expect issue with old distros we support. Should I add this WA and > use %{_pkgdocdir} instead? Yes, please. > >> %doc %{_datadir}/doc/ucx/examples > > I believe it is unnecessary to use the explicit "%doc" marking. RPM automatically marks files under _pkgdocdir as documentation. > Will move %{_datadir}/doc/ucx/examples out of %doc tag. You still have: %doc %{_datadir}/doc/ucx/examples in the "%files devel" section in the current version. Here the %doc tag is simply redundant. > > I am not sure how safe it is to mix the usage of both %doc with relative paths (for README, etc.) and _docdir / _pkgdocdir. The guidelines forbid it if I'm reading them correctly: > > https://fedoraproject.org/wiki/Packaging:Guidelines#Documentation > > I see no obvious issue in the built packages, but maybe it could cause trouble with other versions of RPM. Better avoid the mixed usage by installing the files README, AUTHORS, NEWS into _pkgdocdir in the %install step instead of relying on %doc with relative paths. > Considering the previous paragraph, no issue here, right? It is an issue. You have these two lines: %{_datadir}/doc/ucx %doc README AUTHORS NEWS (The first line should be written as "%{_pkgdocdir}", but that does not change the argument.) The first line uses the method of placing the documentation files in %_pkgdocdir. The second line uses the method of letting RPM copy the files from %_builddir to %_pkgdocdir. According to my reading of the guidelines, these two methods must not be both used in the same source package. > >> # UCX ships both static and dynamic libs to support different use-cases > > I still don't get what the usecase is. Is it for performance reasons? > Yes. OK, can you please mention "for performance" in the comment rather than the vague "to support different use-cases"? -- 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 To unsubscribe send an email to package-review-leave@xxxxxxxxxxxxxxxxxxxxxxx
