https://bugzilla.redhat.com/show_bug.cgi?id=1386938
--- Comment #12 from Zbigniew Jędrzejewski-Szmek <zbys...@in.waw.pl> ---
# Force default attrs because libprelude force others
%defattr(- , root, root, 755)
→ I think you don't need this anymore.
%{python3_sitearch}/_prelude.*so
%{python3_sitearch}/prelude.py
→ Not a packaging issue, but still something to reconsider upstream. I think
putting a private module at the top level is rather ugly. Imaging the mess if
everybody did that ;). Why not structure this as
%{python3_sitearch}/prelude/__init__.py
%{python3_sitearch}/prelude/_prelude.*so
? (Please note that I'm just complaining here, this review is not contingent on
this in any way.)
BR: perl-generators is needed according to
http://fedoraproject.org/wiki/Packaging:Perl#Build_Dependencies,
and also R: perl(:MODULE_COMPAT), see
http://fedoraproject.org/wiki/Packaging:Perl#Versioned_MODULE_COMPAT_Requires.
- Provides: bundled(gnulib) in place as required.
Note: Bundled gnulib but no Provides: bundled(gnulib)
See:
http://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries#Requirement_if_you_bundle
- Note: License file LICENSE.README is not marked as %license
Yeah, it seems reasonable to include that in %license too.
Same goes for HACKING.README.
- Large documentation must go in a -doc subpackage. Large could be size
(~1MB) or number of files.
Note: Documentation size is 5703680 bytes in 53 files.
See:
http://fedoraproject.org/wiki/Packaging/Guidelines#PackageDocumentation
I'm not sure how exactly fedora-review arrives at this number, but it seems
that there's indeed a few MBs of documentation. You might want to split out
libprelude-doc subpackage with /usr/share/doc/libprelude-devel/libprelude.
(Also not that there's an extra level of directories nesting here that looks
accidental.)
rpmlint also says:
libprelude-debuginfo.x86_64: E: incorrect-fsf-address
/usr/src/debug/libprelude-3.1.0/src/libprelude-error/code-to-errno.h
libprelude-debuginfo.x86_64: E: incorrect-fsf-address
/usr/src/debug/libprelude-3.1.0/src/libprelude-error/err-sources.h
libprelude-debuginfo.x86_64: E: incorrect-fsf-address
/usr/src/debug/libprelude-3.1.0/src/libprelude-error/strsource.c
libprelude-debuginfo.x86_64: E: incorrect-fsf-address
/usr/src/debug/libprelude-3.1.0/src/libprelude-error/code-from-errno.h
libprelude-debuginfo.x86_64: E: incorrect-fsf-address
/usr/src/debug/libprelude-3.1.0/src/libprelude-error/err-codes.h
libprelude-debuginfo.x86_64: E: incorrect-fsf-address
/usr/src/debug/libprelude-3.1.0/src/libprelude-error/strerror.c
It's not a big issue, but probably to fix upstream at some point.
libprelude.x86_64: W: crypto-policy-non-compliance-gnutls-2
/usr/lib64/libprelude.so.23.3.0 gnutls_priority_init
prelude-tools.x86_64: W: crypto-policy-non-compliance-gnutls-1
/usr/bin/prelude-admin gnutls_priority_set_direct
This one is a bigger problem. It's been a while since I looked at the details,
but basically you need to call gnutls_set_default_priority or
gnutls_priority_set_direct("@SYSTEM")
[https://fedoraproject.org/wiki/Packaging:CryptoPolicies]. If this policy does
not apply to this package for some reason, please explain in a comment in the
spec file. Looking at ./prelude-admin/server.c, it should be easy enough to
patch.
libprelude.x86_64: W: unused-direct-shlib-dependency
/usr/lib64/libprelude.so.23.3.0 /lib64/libdl.so.2
libprelude.x86_64: W: unused-direct-shlib-dependency
/usr/lib64/libprelude.so.23.3.0 /lib64/libgpg-error.so.0
libprelude.x86_64: W: unused-direct-shlib-dependency
/usr/lib64/libpreludecpp.so.8.1.0 /lib64/libgnutls.so.30
libprelude.x86_64: W: unused-direct-shlib-dependency
/usr/lib64/libpreludecpp.so.8.1.0 /lib64/libgcrypt.so.20
libprelude.x86_64: W: unused-direct-shlib-dependency
/usr/lib64/libpreludecpp.so.8.1.0 /lib64/libdl.so.2
libprelude.x86_64: W: unused-direct-shlib-dependency
/usr/lib64/libpreludecpp.so.8.1.0 /lib64/libgpg-error.so.0
libprelude.x86_64: W: unused-direct-shlib-dependency
/usr/lib64/libpreludecpp.so.8.1.0 /lib64/libltdl.so.7
libprelude.x86_64: W: unused-direct-shlib-dependency
/usr/lib64/libpreludecpp.so.8.1.0 /lib64/libm.so.6
Overlinking? Not a big issue, because those libraries are going to be installed
anyway, but removing it might reduce memory usage and startup time but some
minuscule amount.
And one more suggestion for upstream reconsideration:
custom autoconf macros are horrible. The problem is that any project that wants
to use them, must either bundle them (which is annoying if you have more than
two or three dependencies), or wrap the calls to those macros in ugly and
brittle m4 macros for the case when the dependency is not installed. Please
consider providing a pkgconfig file, which is easier to write, easier to use,
and as a bonus, works with other build systems like meson. (Please note that
I'm just complaining here, this review is not contingent on this in any way.)
--
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@lists.fedoraproject.org
To unsubscribe send an email to package-review-le...@lists.fedoraproject.org
