$ rpmlint libsexy-0.1.1-1.i386.rpm
E: libsexy library-without-ldconfig-postin /usr/lib/libsexy.so.0.0.0
E: libsexy library-without-ldconfig-postun /usr/lib/libsexy.so.0.0.0

Based on the PackageReviewGuidelines, I assume this really is an error. 
However, without any changes to the spec, I was able to build and run a small
demo app using the SexyUrlLabel.  Still, it's a MUST, so I'm pointing it out.

Good:

- package name good, spec file name good
- license is LGPL, matches upstream
  - based on the new package guidelines, you can (should?) remove the extra
COPYING.LIB
- spec file is legible, written in am. english
- source matches upstream
- builds cleanly in mock (FC-3 i386)
- built and tested successfully (FC-4 i386)
- files and directories okay
- -devel subpackage good

Nitpicks:

I think the summary and description are too vague and boring for a package with
the name "libsexy."

(In reply to comment #1)
> Nitpicks:
> 
> I think the summary and description are too vague and boring for a package with
> the name "libsexy."

Yeesh. Everyone's a critic.

Updated.

We had this discussion some time ago, regarding .pc files, that if,
as libsexy does:

Cflags: -I${includedir}

This means that if libsexy installs /usr/include/libsexy/foo.h you can
use the pkg-config flags to get

#include <foo.h>

to work, but this is questionable design, because if you're writing a
whole new library, it is better to remove the -I statement and rely on
all code using libsexy to do:

#include <libsexy/foo.h>

instead. If the library is already used in lots of software it is of
course not so good to do this change to upstream, otherwise it is good
to get upstream to remove the -I statement from the .pc file.

From libsexy.pc:

includedir=${prefix}/include

And it installs into /usr/include/libsexy, so all your concern is for naught.

Rpmlint is happy.  I'm happy.  Approved.

Build on FC4 and devel.