https://bugzilla.redhat.com/show_bug.cgi?id=1474033 --- Comment #22 from Michal Schmidt <mschmidt@xxxxxxxxxx> --- > Source: https://github.com/amaslenn/%{name}/releases/download/v1.2.2/ucx-1.2.2.tar.gz I see you respun the 1.2.2 tarball to move the documentation files. Modifying previously released tarballs without updating the version number is confusing to your users and downstream distributors. The github links on http://www.openucx.org suggest that the canonical upstream repository is https://github.com/openucx/ucx. Perhaps the purpose of your personal fork (amaslenn/ucx) is to make the package pass this review and then you plan to merge the changes into the openucx/ucx repository and do a real (and no longer changing) 1.2.2 release? Do you then intend to change the Source tag in the spec file to point to https://github.com/openucx/ucx? > %{_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}} > %doc %{_datadir}/doc/ucx/examples I believe it is unnecessary to use the explicit "%doc" marking. RPM automatically marks files under _pkgdocdir as documentation. 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. > # 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? I see the sources include some unit tests. Have you considered running them in the %check step of the rpm build? -- 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
