[Bug 190139] Review Request: rapidsvn - Graphical interface for the Subversion version-control system

[bugzilla at redhat.com]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug report.

Summary: Review Request: rapidsvn - Graphical interface for the Subversion version-control system


https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=190139





------- Additional Comments From tibbs at math.uh.edu  2006-04-27 21:55 EST -------
Oops, it seems I took this package by mistake, but I'll go ahead and do a review.

Right off, there's a build failure on x86_64:
checking for Subversion headers... found
checking for Subversion libraries... not found
configure: error: Subversion libraries are required. Try --with-svn-lib.
error: Bad exit status from /var/tmp/rpm-tmp.54929 (%build)

RPM build errors:
    Bad exit status from /var/tmp/rpm-tmp.54929 (%build)
Error building package from rapidsvn-0.9.1-1.src.rpm, See build log
ending

However, the build succeeds on i386.  My assumption is that it isn't checking
/usr/lib64 for the subversion libraries.  You can probably pass
--with-svn-lib="/usr/lib /usr/lib64" to build everywhere.

Issues:
You include the COPYING file, but it contains only the string "Fill me in with
licensing information".  The actual license is more complex than just GPL, it
seems.  LICENSE.txt contains all of the details, so it should probably be
packaged.  I think "GPL and LGPL" would be a more appropriate license tag.

Is autoconf really required?  I didn't see it being called in the build log, and
removing it doesn't seem to hurt anything.

rpmlint complains:
E: rapidsvn library-without-ldconfig-postin /usr/lib/libsvncpp.so.0.0.0
E: rapidsvn library-without-ldconfig-postun /usr/lib/libsvncpp.so.0.0.0

You need to call ldconfig in %post and %postun: see
http://fedoraproject.org/wiki/ScriptletSnippets (the "Shared Libraries" section).

W: rapidsvn devel-file-in-non-devel-package /usr/lib/libsvncpp.so

The guidelines indicate that if you have a versioned .so, the unversioned one
must go in a -devel package.

It seems there's a bunch of headers included in /usr/include; those should
probably go in a -devel package as well.  (Well, they're .hpp files, which I
haven't seen before, but they look like C++ class definitions.)

There does seem to be some kind of test suite (in src/tests/svncpp), but I'm not
sure how you would go about calling it.  This isn't a blocker, but you might
want to take a look.

Review:
* package meets naming and packaging guidelines.
* specfile is properly named, is cleanly written and uses macros consistently.
X license field matches the actual license.
X license is open source-compatible and included upstream but is not included in
the package.
* source files match upstream:
   ba03034db35912c7b51b146cc7e6090e  rapidsvn-0.9.1.tar.gz
   ba03034db35912c7b51b146cc7e6090e  rapidsvn-0.9.1.tar.gz-srpm
? BuildRequires are proper (not sure about autoconf)
X package fails to build in mock (development, x86_64).
X rpmlint is silent.
O final provides and requires are sane.
X shared libraries are present; ldconfig should be called but isn't.
* package is not relocatable.
* owns the directory it creates.
* doesn't own any directories it shouldn't.
* no duplicates in %files.
* file permissions are appropriate.
* %clean is present.
O %check not present; there seems to be an upstream test suite, but it's not
immediately obvious how it would be called.
* code, not content.
* documentation is small, so no -docs subpackage is necessary.
* %docs are not necessary for the proper functioning of the package.
X headers present in main package.
* no pkgconfig files.
* no libtool .la droppings.
* a GUI app; desktop file properly installed with desktop-file-install.


-- 
Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.