Bug 998591

Summary: Please drop the perl(Data::UUID) compat shim so the real Data::UUID can be introduced
Product: [Fedora] Fedora Reporter: Paul Howarth <paul>
Component: uuidAssignee: Steven Pritchard <steve>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 19CC: mhlavink, steve
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: uuid-1.6.2-23.fc21 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-09-16 12:38:54 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 998143    
Bug Blocks: 998235    
Attachments:
Description Flags
Sample implementation none

Description Paul Howarth 2013-08-19 14:42:25 UTC 
Created attachment 788099 [details]
Sample implementation

The perl module Data::UUID shipped as part of the uuid-perl package is an old fork of Data::UUID from upstream (CPAN) done by debian apparently due to license concerns that turned out to be unfounded (see http://bugs.debian.org/717430).

Upstream took a dim view of this, noting in the changelog (https://metacpan.org/source/RJBS/Data-UUID-1.148/Changes):

  - Debian has chosen to distribute their own Data::UUID, which has a different
    interface and breaks other modules.  They also use a grossly-inflated
    version number, which means that this version number must be inflated to
    allow modules to rely on the CPAN Data::UUID properly.
 
    Tests added to EXPLICITLY assert the one known difference between genuine
    Data::UUID and Debian's ersatz version in libossp-uuid-perl.
 
    Thanks to ADAMK for bringing this to my attention.

I need Data::UUID from CPAN for another module I'm packaging (perl-Object-ID - Bug #998235) and so I have submitted a package review for perl-Data-UUID (Bug #998143).

I propose that the uuid-perl package drops its Data::UUID implementation and instead requires perl(Data::UUID) from my package, so that users of uuid-perl suffer no loss of functionality. My proposed package change (attached) also adds perl(Data::UUID) as a build requirement and runs the compatibility test suite to check that the CPAN implementation produces the expected results, i.e. this change introduces no regressions.
Comment 1 Paul Howarth 2013-09-04 11:55:07 UTC 
Michal, do you have any objection to me making this change? I'm not expecting any response from Steve, who doesn't seem to have had any involvement in Fedora for over a year now.
Comment 2 Michal Hlavinka 2013-09-04 17:04:59 UTC 
> - Debian has chosen to distribute their own Data::UUID, which has a different
> interface and breaks other modules.

won't your change break applications that expect this different interface?
Comment 3 Paul Howarth 2013-09-04 18:02:45 UTC 
Looking into this a bit more, it seems that the incompatibility was fixed upstream in uuid 1.6.0. The debian bug report is http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=480451 and the upstream changelog entry says:

   o Fix the Data::UUID::to_b64string() function of the Perl backward
     compatibility API: an empty string was not supplied as the EOL
     marker to MIME::Base64::encode_base64() and hence the returned
     string ended with a newline character (which in turn breaks many
     applications using Data::UUID).
     [Piotr Roszatycki <dexter>]

This may explain why running the uuid test suite using CPAN's Data::UUID worked OK, unless there was no test for that issue.

So the main issue is which is the canonical upstream for perl(Data::UUID), and hence should be shipped in Fedora - I would say the CPAN version.
Comment 4 Michal Hlavinka 2013-09-16 12:38:54 UTC 
I was thinking about this a lot and I'm not 100% sure I like the idea of changing it when it's not broken. Anyway, I'll do the above change in rawhide only and see how big impact it has.