https://bugzilla.redhat.com/show_bug.cgi?id=1474033
--- Comment #25 from Michal Schmidt <[email protected]> --- (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 -- [email protected] To unsubscribe send an email to [email protected]
