Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • 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 [ossp.org], 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
    • 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.