[Bug 717337] Review Request: URCU - Userspace RCU Implementation
bugzilla at redhat.com
bugzilla at redhat.com
Sun Sep 18 12:01:02 UTC 2011
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=717337
Michael Schwendt <mschwendt at gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |mschwendt at gmail.com
--- Comment #7 from Michael Schwendt <mschwendt at gmail.com> 2011-09-18 08:00:59 EDT ---
Several of the findings in comment 2 have not been added to the spec file and
have not been commented on either. Please respond to reviewers' comments even
if you disagree with them.
> License: LGPL v2 or later
The correct license identifier really is "LGPLv2+" as pointed out in comment 2.
The related guidelines are these:
https://fedoraproject.org/wiki/Packaging:LicensingGuidelines#Valid_License_Short_Names
Writing this comment I noticed the linked spec file is out-of-date and doesn't
match the latest src.rpm. Hmmm... continueing with the src.rpm then:
> License: LGPLv2
So, same comment as above applies. ;)
> Name: liburcu
> Group: Development/Libraries
Dunno whether or when RPM will get rid of these Group tags (if at all), but
library base packages typically belong into
Group: System Environment/Libraries
> %description
> Userspace RCU (Read-Copy-Update) Implementation from the LTTng project.
Very brief and reads more like a summary. The top lines at
http://lttng.org/urcu/ contain a somewhat more detailed description that could
be copied and modified slightly to build a more detailed description:
| This package contains liburcu, a userspace RCU (read-copy-update)
| library. This data synchronization library provides read-side access
| which scales linearly with the number of cores. It does so by allowing
| multiples copies of a given data structure to live at the same time,
| and by monitoring the data structure accesses to detect grace periods
| after which memory reclamation is possible.
What do you think?
> ExclusiveArch: %ix86 x86_64 ppc ppc64 s390 s390x
Based on
http://fedoraproject.org/wiki/Architectures#ExcludeArch_.26_ExclusiveArch
I recommend dropping this, especially since no spec file comment gives a strong
rationale.
> %package -n liburcu-devel
> Requires: liburcu = %{version}-%{release}
Be aware of %{?_isa} having entered the guidelines as a MUST item:
https://fedoraproject.org/wiki/Packaging:Guidelines#Requiring_Base_Package
> autoreconf -fvi
No strong feelings here. Just know that depending on what versions of the GNU
Autotools may be required by the liburcu build files, a full autoreconf may
cause broken builds. Sometimes without terminating the RPM package build job.
> make %{?_smp_mflags}
For more verbose build.log output, this one works:
V=1 make %{?_smp_mflags}
> %files -n liburcu-devel
> %{_prefix}/include/*
Note that %{_includedir} exists, too, and is the one set by the %configure
macro.
As convenient as wildcards may be, with some packages, it can also be
beneficial to be a little bit more specific about what file names to include,
e.g.
%{_includedir}/urcu*
or even
%{_includedir}/urcu/
%{_includedir}/urcu*.h
would implicitly protect against unexpected renames during package version
upgrades. You would learn about substantial changes below %_includedir due to
the build failing. Not mandatory, of course.
> %{_libdir}/*.a
https://fedoraproject.org/wiki/Packaging:Guidelines#Packaging_Static_Libraries
> # rpmlint *
> liburcu.x86_64: W: shared-lib-calls-exit /usr/lib64/liburcu-qsbr.so.1.0.0
> exit at GLIBC_2.2.5
and several more. Please find out why/when it calls exit and whether you can
get rid of this.
> liburcu-debuginfo.x86_64: E: incorrect-fsf-address /usr/src/debug/userspace-rcu-0.6.3/urcu/list.h
> liburcu-devel.x86_64: E: incorrect-fsf-address /usr/include/urcu/rcuhlist.h
> liburcu-devel.x86_64: E: incorrect-fsf-address /usr/include/urcu/rculist.h
> liburcu-devel.x86_64: E: incorrect-fsf-address /usr/include/urcu/list.h
Please try to get this fixed in the upstream tarball. 0.6.4 is available, btw.
> %doc README LICENSE
https://fedoraproject.org/wiki/Packaging:LicensingGuidelines#License_Text
--
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
More information about the package-review
mailing list