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 ]

hex (3272)

hex
  (email not shown publicly)
http://downlode.org/
Perl, RDF and wiki hacker, London, UK. This is my former Perl blog; I now write at Earle's Notebook [downlode.org].

Journal of hex (3272)

Thursday May 08, 2008
03:56 PM

backpan considered dangerous

[ #36361 ]

The recent discussion about potential version control for all CPAN reminded me of a thought I've had for a while about backpan - namely that it is dangerous and ill-thought-out in its current state.

As it stands, it's impossible to remove anything from backpan, for any reason. So in backpan we have a gigantic minefield of potentially dangerous bugs and possibly even licensing-related legal issues.

How dangerous? How about rm -rf / dangerous? (Sorry Adam.)

A mechanism to Delete Forever is needed before somebody does themselves or their data harm. In the meantime, a big red PERIGO MINAS sign ought to be put on the front page. Actually having a front page for backpan first would also help; the just-dump-the-user-in-a-directory-listing look went out of fashion well over a decade ago.

Posted to use.perl because I'm not sure where to suggest this. Meant in good faith. Thanks.


List all Journal entries
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

backpan considered dangerous 17 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • Is there anything you've said about BackPAN which does not also apply to CPAN?

    Don't forget, a passive repository is harmless /until/ a human (directly or via a program) intervenes...
    • The big difference being that backpan contains all the files deleted from cpan, and those files were deleted for a reason.
      • Not such a difference.

        To delete V 1.00 because V 1.01 is better makes sense, but you're assuming V 1.01 is perfect, whereas in time CPAN (V 1.01) will be deemed just as faulty because V 1.02 will come along...
        • I'm not assuming anything of the kind. I think you've misunderstood.
          • Nope. But I see further discussion is pointless.
            • I'll rephrase what hex said. Sometimes modules (not just releases) are deleted from CPAN. For a reason.
              • Yes, absolutely. I hadn't thought of that, and it's a very serious addition to the point I was making.
            • Look. My point was, files are removed from CPAN because their replacement either (a) adds something new or (b) fixes something wrong. It's the old files with something wrong that we need to be worried about.

              Your comment about deleting V 1.00 because V 1.01 is better really doesn't have anything to do with the point of my journal entry.

        • I don’t see that assumption anywhere.

          The reason for deleting 1.00 and putting up 1.01 may have been that it is known to have contained a catastrophic bug. Whether or not 1.01 is perfect is irrelevant; we don’t know yet. The point is, we do know, and we know right now, that some fraction of the software on BackPAN is dangerous.

  • Let me introduce you to the Internet Archive [archive.org].

  • I think it's a good idea to have a warning, assuming people can stumble onto backpan and not realize that it's an archive meant only for historical record and is not the real CPAN. And I think you're right about the copyright/licensing issues; a module author doesn't necessarily hand over a module to the public domain just because it was uploaded to CPAN, or maybe it should just be explicit that by uploading something to CPAN you forfeit your rights to restrict the module's distribution? (or haven't you?)

    O

    • Personally, I like BackPAN the way it is and wouldn’t want things on it to be deletable forever, because I think of it as an archæological record. The mistakes of the past should conserved with equal prominence to its achievements.

      But it sure would be handy if there was a way to flag known bad stuff so people are forewarned.

      a module author doesn’t necessarily hand over a module to the public domain just because it was uploaded to CPAN

      Well, by uploading to the CPAN, you have distribu

  • You unquestionably have a point. And for licensing reasons, files actually *have* been deleted from the backpan in the past. But this is manually and can be done by admins only. Since this isn't a very frequent occurrence, that's fine in terms of workload and workflow. I'm talking about the semi-official backpan.perl.org, of course. Everybody could potentially run his own kind of backpan by just copying over anything in the recent submissions to CPAN. There's no controlling that.

    Now, the real value of backp
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.