Bugzilla Bug 167649

From their homepage:
---------------------------------------------------------------
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.

UUIDs are 128 bit numbers which are intended to have a high likelihood of
uniqueness over space and time and are computationally difficult to guess. They
are globally unique identifiers which can be locally generated without
contacting a global registration authority. UUIDs are intended as unique
identifiers for both mass tagging objects with an extremely short lifetime and
to reliably identifying very persistent objects across a network. 
----------------------------------------------------------------------


Reproducible: Always

This package collide with other uuid implementations (the one in e2fsprogs) and
break lots of things.

Debian renames this library from uuid to ossp-uuid. But maybe it's better to
install it on ossp/uuid.* (instead of ossp-uuid.*).

I'm looking into the possibility of storing the libraries in a subdirectory and
trying to come up with an ebuild.  I'll post my findings tomorrow.

Created an attachment (id=120933) [details]
Suggested ebuild

This is an ebuild I put together for the latest version of OSSP's uuid library.
 It installed well on my x86.  I still have to test if I can actually still use
both the old libuuid that was already present and the OSSP one.  This ebuild
shouldn't overwrite any existing libraries as the prefixes are set so that
libraries/includes are stored under ossp/ in their respective directories.

I was thinking the ossp/ directory is the best way to go providing it works. 
Considering there are so many other OSSP libraries available, then future
ebuilds for them could also be placed in those directories.

Well, if anyone has any ideas regarding the ebuild, let me know.  I'd be happy
to be a proxy maintainer for this if the developers are looking for someone to
maintain it.

On my x86, it installs without collisions and passes the test suite.

I compiled MyPasswordSafe against it but it fails at link time.

Created an attachment (id=120944) [details]
ossp-uuid-1.6.0.ebuild

Added --with(out)-perl-compat, made the ebuild multilib friendly,  and did some
trivial clean-up.

Created an attachment (id=120967) [details]
ossp-uuid-1.6.0.ebuild

Added --with-pgsql support and the proper dependency

Created an attachment (id=120969) [details]
ossp-uuid-1.6.0-pg_config.patch

This is the patch for the latest ebuild.  It patches the Makefile for the pgsql
compatibility library.  Adds pg_config's --includedir, --includedir-server, and
--libdir files.

Well, is in the tree now.
I did it the same way as debian did it. The problem when installing the lib as
libuuid.so in a sub-directory, the only option for apps linking against those
libs is to use RPATH, which is rather difficult and requires a lot of manual
packaging.