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

use Perl Log In

Log In

[ Create a new account ]

Debian Removes perlreftut

posted by Simon on 2003.08.13 7:19   Printer-friendly
davorg writes "It seems that Debian have decided to remove "perlreftut" from their distribution. Full discussion here." Legalism 1, pragmatism 0.
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.
  • I'm a free software fanatic (well, sometimes), and I appreciate Debian sticking to their guns ... but last I checked the Perl Artistic License was a free software license, so I'm not sure what the problem is.

    --
    J. David works really hard, has a passion for writing good software, and knows many of the world's best Perl programmers
    • Quoting from Don Armstrong's post (Message-ID: ), the problem is as follows:

      "DFSG 10 says that the Artistic license can be assumed to meet the DFSG."

      It does, but we're not dealing with the Artistic license here... this is an Artistic License with an additional rider with strange interactions.

      The "rider" (right at the top of the discussion) is:

      "Distribution Conditions"

      Copyright 1998 The Perl Journal.

      When included as part of the Standard Version of Perl, or as part of its complete documentation wheth

      • I've personally about had it up to here with contradictory distribution guidelines. I'm fed up with people who want to say, "This software is GPL unless you put it on a CD." I support every author's right to set distribution terms for their own software, but from one programmer to another, I want to say, "If you don't get the point, stay out until you do."

        More and more licenses keep popping up, and more and more special exceptions. All this does is make things confusing. I think the best advice I ever

        --
        J. David works really hard, has a passion for writing good software, and knows many of the world's best Perl programmers
      • Oh, and it seems to me that splitting out the file into a non-free package and distributing it breaks the author's terms. At that point, it's not part of the Perl distribution!

        --
        J. David works really hard, has a passion for writing good software, and knows many of the world's best Perl programmers
    • From my reading of the thread from the Debian bug list, the issue centers around the distribution conditions outlined in the perlreftut document.

      These conditions limit the distribution of the document outside of the "standard version" of Perl or as part of its complete documentation without special arrangement from the copyright holder (TPJ). This contravenes the first point of the Debian Free Software Guidelines (DFSG) [debian.org] which mandate free redistribution - From the Debian Free Software Guidelines:

      The lice

  • Maybe I'm reading it wrong, but the message (currently) at the bottom of the link you provided says that the license of perlreftut was updated (presumably to "same as Perl"), and the problem no longer exists. That was dated Jul 29...

    (Though I have to admit I'm confused about the non-free status too)

    • I don't know if anything changed in perlreftut. Google Groups doesn't know about any change.

      Anyway, the *current* perl in Debian does not include perlreftut. :(
  • Irrelevant (Score:2, Interesting)

    The maintainers of perl for various platforms seem to all have failed to have working installations of perl anyways. At least I cannot remeber when I last used a system installed perl for anything I did or installed. It would all just break break break with things installed of CPAN.

    Frankly, it is just silly hair splitting.

    --
    sky
    • Don't you always do things that involves ithread support ? ;-)
      • Re:Irrelevant (Score:2, Interesting)

        Not at all! I have multiple perls installed :)

        /usr/local/perl/58/
        /usr/local/perl/58t/
        /usr/local/perl/58td/
        /usr/local/perl/58d/
        /usr/local/perl/58_64/
        /usr/local/perl/bl/
        /usr/local/perl/bld/
        /usr/local/perl/blt/
        /usr/local/perl/mtd/

        And so on :)

        --
        sky
    • Re:Working Perl (Score:2, Insightful)

      Package management systems like dpkg and rpm simply don't cooperate with CPAN. They need to know what files are installed and what packages installed them, and CPAN installations are far too undisciplined to report what's been installed and where (and, even more important in some ways, what's been removed). And then there are the dependency tracking issues.

      In short, if you use rpm or dpkg, you shouldn't be using CPAN in the first place. This has nothing to do with the skill or dedication of the package

      • Certainly in Debian, a few CPAN modules are packaged as libfoo-perl. There has been talk IIRC of a Debian-specific version of CPAN.pm or something similar which will inform apt (probably by wrapping the equivs package) when new perl modules are installed or upgraded by CPAN.

        It would in theory be possible to "automatically" convert every module on CPAN to a Debian module. Perhaps we need to set up apt.perl.org as some kind of automagic gateway ;)

        • It would in theory be possible to "automatically" convert every module on CPAN to a Debian module.

          In practice too. Well, not *every* module, but every module that is packaged in the standard way can be very easily compiled into a .deb:

          apt-get install dh-make-perl

          dh-make-perl --build --cpan Foo::Bar
          or
          dh-make-perl --build --cpanplus Foo::Bar

          You can supply --install if you want the new .deb to be installed immediately.

        • Re:Working Perl (Score:2, Informative)

          It would in theory be possible to "automatically" convert every module on CPAN to a Debian module. Perhaps we need to set up apt.perl.org as some kind of automagic gateway ;)

          This is already possible on the *BSD systems, with a clever hack called BSDPAN. This is a modification to the Perl build on those systems that sticks some hooks in to the ExtUtils::* modules, so that 'perl Makefile.PL; make; make test; make install' also registers the module's files with the local package management system.

          BSDPA [pm.org]

        • I have just started to use and I am quite happy of cpan2rpm [arix.com], which of course could be enhanced in a number of ways.
        • Gentoo has done it already... i.e.
          #g-cpan.pl MODULE
          makes a .ebuild and installs the module
      • In short, if you use rpm or dpkg, you shouldn't be using CPAN in the first place I assume you mean that you should be wrapping CPAN modules into RPMs or DEBs for local use rather than using the CPAN.pm system to install. I would agree with that. If you're suggesting that you should not be using CPAN as a whole, then I would strongly disagree. That's what makes Perl as useful as it is!
        --
        Yet Another Just another perl hacker, // essays.ajs.com
  • I don't see that this is a serious issue. Not at the moment anyway. Debian have noticed something which might violate their terms of distribution, and as a precautionary measure they've removed it from their packages. If that removal was in itself against the terms of somebody's license, then they're in a no-win position so it doesn't really matter which evil they commit.

    Instead of pointing fingers and bashing Debian for doing things in a particular way, we need a nice mature discussion between the Perl a