Bug 192564 - Review Request: uuid
Review Request: uuid
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jason Tibbitts
Fedora Package Reviews List
:
Depends On:
Blocks: FE-ACCEPT 192575
  Show dependency treegraph
 
Reported: 2006-05-20 15:46 EDT by Steven Pritchard
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-05-29 19:12:45 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Steven Pritchard 2006-05-20 15:46:27 EDT
Spec URL: http://ftp.kspei.com/pub/steve/rpms/uuid/uuid.spec
SRPM URL: http://ftp.kspei.com/pub/steve/rpms/uuid-1.4.2-1.src.rpm
Description:
OSSP uuid is a ISO-C:1999 application programming interface (API)
and corresponding command line interface (CLI) for the generation
of DCE 1.1, ISO/IEC 11578:1996 and RFC 4122 compliant Universally
Unique Identifier (UUID). It supports DCE 1.1 variant UUIDs of version
1 (time and node based), version 3 (name based, MD5), version 4
(random number based) and version 5 (name based, SHA-1). Additional
API bindings are provided for the languages ISO-C++:1998, Perl:5 and
PHP:4/5. Optional backward compatibility exists for the ISO-C DCE-1.1
and Perl Data::UUID APIs.
Comment 1 Jason Tibbitts 2006-05-23 16:16:49 EDT
I think the license is essentially the MIT license:
http://www.opensource.org/licenses/mit-license.php
It's probably a better fit than "Distributable".

rpmlint, as usual, finds something to complain about:

E: uuid binary-or-shlib-defines-rpath /usr/bin/uuid ['/usr/lib64']
W: uuid unstripped-binary-or-object /usr/lib64/libuuid.so.14.0.22
W: uuid-c++ unstripped-binary-or-object /usr/lib64/libuuid++.so.14.0.22
W: uuid-c++ no-documentation
W: uuid-dce unstripped-binary-or-object /usr/lib64/libuuid_dce.so.14.0.22
W: uuid-dce no-documentation
W: uuid-dce-devel no-documentation
W: uuid-pgsql no-documentation
W: uuid-php no-documentation

The no-documentation ones are OK.  The unstripped object warnings are
problematic; I don't know what to do about those.  The rpath problem can be made
to go away by adding:

BuildRequires: libtool

then changing the make line to:

make LIBTOOL=/usr/bin/libtool %{?_smp_mflags}

and then adding this after the make install:

rm -f $RPM_BUILD_ROOT%{_libdir}/*.a

* package meets naming and packaging guidelines.
* specfile is properly named, is cleanly written and uses macros consistently.
* dist tag is present.
? license field matches the actual license.
* license is open source-compatible.  License text included in package.
* source files match upstream:
   fdfe93bc134dfb73814456c3b444dda1  uuid-1.4.2.tar.gz
   fdfe93bc134dfb73814456c3b444dda1  uuid-1.4.2.tar.gz-srpm
* latest version is being packaged.
* BuildRequires are proper.  (I didn't realize you could list them in the
subpackage declarations.)
* package builds in mock (development, x86_64).
X rpmlint complains of rpath and unstripped libraries.
* final provides and requires are sane.
* shared libraries are present; ldconfig is called where necessary.  (Some
libraries are internal to Perl, PHP, pgsql, etc. so ldconfig is not called for
those packages.)  Unversioned libraries are in -devel subpackages.
* packages are not relocatable.
* own the directories they creates.
* doesn't own any directories it shouldn't.
* no duplicates in %files.
* file permissions are appropriate.
* %clean is present.
* %check is present and all tests seem to pass.
* scriptlets present and quite sane.
* code, not content.
* documentation is small, so no -docs subpackage is necessary.
* %docs are not necessary for the proper functioning of the package.
* headers are in -devel subpackages.
* no pkgconfig files.
* no libtool .la droppings.
* not a GUI app.
Comment 2 Steven Pritchard 2006-05-23 17:43:23 EDT
(In reply to comment #1)
> I think the license is essentially the MIT license:
> http://www.opensource.org/licenses/mit-license.php
> It's probably a better fit than "Distributable".

OK.  Fixed in -2.

> rpmlint, as usual, finds something to complain about:
> 
> E: uuid binary-or-shlib-defines-rpath /usr/bin/uuid ['/usr/lib64']
> W: uuid unstripped-binary-or-object /usr/lib64/libuuid.so.14.0.22
> W: uuid-c++ unstripped-binary-or-object /usr/lib64/libuuid++.so.14.0.22
> W: uuid-c++ no-documentation
> W: uuid-dce unstripped-binary-or-object /usr/lib64/libuuid_dce.so.14.0.22
> W: uuid-dce no-documentation
> W: uuid-dce-devel no-documentation
> W: uuid-pgsql no-documentation
> W: uuid-php no-documentation
> 
> The no-documentation ones are OK.

Agreed.

> The unstripped object warnings are problematic; I don't know what to do about
those.

I don't either.  I'm assuming the auto-strip magic is breaking for some reason,
but I can't imagine what that reason is...

> The rpath problem can be made to go away by adding:
[libtool stuff]

I tried that, but I still get the %{_libdir} rpath.  Is that really an issue?

I fixed a build directory rpath problem in the PHP module, BTW.  Trying a
similar fix for the %{_libdir} rpath thing (introduced, I'm 99% sure, by a
-rpath in Makefile.in) results in a failed build.  Well, actually, a failed
install.  Try adding "sed -i -e 's/ -rpath \$(libdir)//' Makefile.in" to %prep
if you want to see what I mean.  I might just be dense, but I don't see how to
fix the problem.
Comment 3 Jason Tibbitts 2006-05-23 18:06:28 EDT
Looks like we need more expertise.

As for rpath, my understanding is that we should do what we can to eliminate it
but that if it's simply not possible then it won't keep the package out.  But
after patching the spec as I suggested I see no trace of rpath.  That technique
has worked for me in the past.

About the unstripped libraries, it looks like they aren't executable, so they
don't get stripped.  I've seen this in the past, and a chmod 755 has fixed it
up, but while looking through /usr/lib/rpm/redhat/brp-strip* I saw this:

# Strip ELF shared objects
# Please note we don't restrict our search to executable files because
# our libraries are not (should not be, at least) +x.

Sometimes it's just so difficult to figure out how things are really supposed to
be done.
Comment 4 Steven Pritchard 2006-05-23 18:32:55 EDT
(In reply to comment #3)
> As for rpath, my understanding is that we should do what we can to eliminate it
> but that if it's simply not possible then it won't keep the package out.  But
> after patching the spec as I suggested I see no trace of rpath.  That technique
> has worked for me in the past.

Weird.  I just tried it again, and it works this time.  I must have changed the
wrong make line or something.

> About the unstripped libraries, it looks like they aren't executable, so they
> don't get stripped.  I've seen this in the past, and a chmod 755 has fixed it
> up, but while looking through /usr/lib/rpm/redhat/brp-strip* I saw this:
> 
> # Strip ELF shared objects
> # Please note we don't restrict our search to executable files because
> # our libraries are not (should not be, at least) +x.

That's interesting.  Just about everything else in my /usr/lib64 is executable.
 And, sure enough, adding in a chmod gets rid of that rpmlint warning.

Try -3, please.
Comment 5 Jason Tibbitts 2006-05-23 19:54:01 EDT
-3 looks good except for this:

W: uuid-php devel-file-in-non-devel-package /usr/lib64/php/modules/uuid.a

I guess this cropped up with your fix for an rpath issue in the PHP module.  I
didn't notice it before but maybe rpmlint just didn't pick it up.

At this point, with the exception of deleting that errant static library I think
we're ready to go.  So I'll approve now and you can clean it up when you check in.

APPROVED
Comment 6 Steven Pritchard 2006-05-24 10:12:52 EDT
(In reply to comment #5)
> -3 looks good except for this:
> 
> W: uuid-php devel-file-in-non-devel-package /usr/lib64/php/modules/uuid.a
> 
> I guess this cropped up with your fix for an rpath issue in the PHP module.  I
> didn't notice it before but maybe rpmlint just didn't pick it up.

Oops.  I didn't notice that.  (And yes, it is new in -3.)  Sorry.

I'm importing -4 into CVS now with that fixed.

$ rpmlint uuid-*1.4.2-4.x86_64.rpm
W: uuid-c++ no-documentation
W: uuid-dce no-documentation
W: uuid-dce-devel no-documentation
W: uuid-pgsql no-documentation
W: uuid-php no-documentation
Comment 7 Steven Pritchard 2006-05-29 19:12:45 EDT
Imported into CVS, branches created, and builds requested.

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