Bug 539472 - Review Request: libmemcache - C API to memcached
Review Request: libmemcache - C API to memcached
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Nobody's working on this, feel free to take it
Fedora Extras Quality Assurance
Depends On:
Blocks: 539469
  Show dependency treegraph
Reported: 2009-11-20 04:45 EST by Jeroen van Meeuwen
Modified: 2009-12-31 08:23 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-12-31 08:23:28 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Jeroen van Meeuwen 2009-11-20 04:45:05 EST
Spec URL: http://www.kanarip.com/custom/SPECS/libmemcache.spec
SRPM URL: http://www.kanarip.com/custom/f13/SRPMS/libmemcache-1.4.0-0.1rc2.fc13.src.rpm
Description: libmemcache is a C API library to the memcached server
Comment 2 Michael Schwendt 2009-11-23 08:34:04 EST
No full review, just some observations:

> rm -rf test/unit
> %{__rm} -rf %{buildroot}

Either use %{__rm} or "rm" consistently, but mixing them only raises doubts about whether using the macro %{__rm} is needed at all?

> %build
> rm -rf test/unit
> sed -i -e 's/unit//g' test/Makefile.am
> sed -i -e 's/test\/unit\/Makefile//g' configure.ac

That's a good example of stuff you ought to add comments to in the spec file. Not only to answer the "Why?" question, but also to confirm what this is supposed to achieve and whether the first sed translation might not kill anything unexpectedly with a future version upgrade.

> %files
> %defattr (-,root,root,-)
> %doc COPYING INSTALL ChangeLog
> ...
> %files devel
> %defattr (-,root,root,-)
> %doc COPYING INSTALL ChangeLog
> ...

Is it really necessary to duplicate %doc files like that? Especially with Fedora, the -devel package requires the base package anyway.

> %{_includedir}/memcache*

'*' as in "many/any"?  Or as in "I don't care whether any version upgrade might move the API headers from to a location that's different from previous releases?

> %{_libdir}/%{name}.so.*

Macros, in particular %{name}, are overrated.  If you wanted to simply rename this package from "libmemcache" to "libmemcache1" or "compat-libmemcache1", you would need to touch the %files section, too. So, %{_libdir}/libmemcache.so.*  would be much more readable.
Comment 3 Remi Collet 2009-12-30 12:53:39 EST
Do you really need this library ? it's seems unmaintained (lastest version is from 2006)

Your Source URL give a 404 and point to http://download.tangent.org/ which host "libmemcached" already available in repository.

Comment 4 Jeroen van Meeuwen 2009-12-31 08:23:28 EST
OpenSRF has been ported to use libmemcached instead. Closing deferred.

Note You need to log in before you can comment on or make changes to this bug.