All the Perl that's Practical to Extract and Report

Why do vendors do this crap?

jk2addict on 2007-03-08T18:02:14

I just noticed a new Data::GUID/UUID release to CPAN. Since I use it heavily in Handel so tend to look at such modules change list just to keep up with things.

1.148 Thu Nov 16 10:21 2006
  - 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.


What the fark is that? Why in the hell did they dist their own, inflate the version and break the API? That's just damn stupid.

It's the License

stu42j on 2007-03-08T18:46:38

The reason is the
license. Basically, Data::UUID doesn't have one.

Providing a mostly compatible API under the same name is probably a bad idea, though.

Re:It's the License

stu42j on 2007-03-08T19:19:51

Actually, the bug in question was supposed to be fixed in the Debian package. There is a patch in the source file but somehow it doesn't make it into the final package.

It should really be fixed upstream.

Re: Why do vendors do this crap?

arc on 2007-03-08T19:54:32

This does sound like a very sucky situation, but I think it's hard to characterise it as the fault of the Debian maintainers.

  • Debian can't (currently) distribute CPAN Data::UUID, because it carries no statement of the terms under which it may be distributed.
  • Debian can (and do) distribute ossp-uuid, Ralf S. Engelschall's C library for generating UUIDs.
  • Ralf's library comes with a Perl module named Data::UUID which purports to be compatible with CPAN Data::UUID. (That is, Ralf Engelschall is the person who decided to reimplement an existing module under a different name and with a different version-number sequence, not the Debian maintainer.)
  • It turns out that Ralf's Data::UUID Perl module has a bug which means it's incompatible with CPAN Data::UUID. That's certainly unfortunate, but it's not actually uncommon in my experience for software to have bugs.

Try as I might, I can't construe this situation in such a way as to apportion blame to the Debian maintainer. You might claim that the Debian maintainer should have avoided packaging the Perl module part of ossp-uuid, but that would break the expectations of people who use ossp-uuid. As it happens, the Debian package instead breaks the expectations of people who use CPAN Data::UUID. But the precise breakage is one that wouldn't have been predictable to the Debian maintainer.

What do you think the Debian maintainer could or should have done differently?

Re: Why do vendors do this crap?

jk2addict on 2007-03-08T20:37:17

I just want to know who to flog heavily with a wet noodle when someone files an RT about "uuid generation not working, I'm getting errors in DBIx::Class::UUIDColumn", and wasting time going "Is Data::UUID installed? Yes. Hmmm....why is it not working...oh wait...which Data::UUID...the Debian version or the CPAN version..."

I realize it's not totally the maintainers fault...but at the same time, some red flag should have gone off when someone says "well, we can't package the CPAN version for licencing reasons, so lets just use this one that's name the same thing instead". Brilliant! :-)

Hey, while you're at it, just rename the Ruby interpreter to Perl. That should work....it's named the same and mostly compatable right?

It just feels like a Redshat-ism. It would be even worse if the @INC is jackered, and installing the CPAN version still doesn't get used because it falls too late in @INC compared to their version.

Re: Why do vendors do this crap?

sigzero on 2007-03-09T12:51:09

Did they try and contact the author?

Re: Why do vendors do this crap?

rjbs on 2007-03-09T16:20:03

No one contacted me. They may have tried to contact Alexander G., whom I've been unable for years.

Welcome to Debian

djberg96 on 2007-03-08T21:03:18

Yet another item in the list of reasons not to use Debian.