backpan considered dangerous

hex on 2008-05-08T20:56:51

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.


CPAN also?

Ron Savage on 2008-05-08T23:06:01

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...

Re:CPAN also?

hex on 2008-05-08T23:32:04

The big difference being that backpan contains all the files deleted from cpan, and those files were deleted for a reason.

Re:CPAN also?

Ron Savage on 2008-05-08T23:38:55

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...

Re:CPAN also?

hex on 2008-05-08T23:41:40

I'm not assuming anything of the kind. I think you've misunderstood.

Re:CPAN also?

Ron Savage on 2008-05-09T00:12:17

Nope. But I see further discussion is pointless.

Re:CPAN also?

runrig on 2008-05-09T00:15:10

I'll rephrase what hex said. Sometimes modules (not just releases) are deleted from CPAN. For a reason.

Re:CPAN also?

hex on 2008-05-09T00:36:18

Yes, absolutely. I hadn't thought of that, and it's a very serious addition to the point I was making.

Re:CPAN also?

hex on 2008-05-09T00:35:16

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.

Re:CPAN also?

Aristotle on 2008-05-09T12:40:28

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.

um...

educated_foo on 2008-05-09T00:39:59

Let me introduce you to the Internet Archive.

Re:um...

hex on 2008-05-09T02:46:33

Which you can remove files from. I should know, I've done it.

Your point?

Re:um...

pudge on 2008-05-15T19:06:25

How do you handle permanent removal on Wikipedia?

Re:um...

hex on 2008-05-15T20:52:04

http://en.wikipedia.org/wiki/Wikipedia:Revision_hiding

IHNJH,IJLS "extreme deletion"...

Re:um...

pudge on 2008-05-15T21:28:22

Maybe something similar (in concept) could be implemented for BackPAN.

comprehensive

slanning on 2008-05-09T10:05:49

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?)

On the other hand, what does the "comprehensive" mean in CPAN? You would no longer have Adam's mistake to point to if you deleted it, for example. Maybe that's not important. But will there be any confusion if authors randomly obliterate their modules? If Adam's module is no longer there, then "what the hell is she talking about?" (someone a few years from now reading your blog)

And if it's easier to permanently delete things, it might also be easier to upload bad shit in the first place. Hah, no - I forgot we're talking about CPAN. :)

Maybe this is part of the struggle between TIMTOWTDI and (how should I say it...) fascism (since I believe TIMTOWTDI :). Are "we" also going to have to add CPAN cops to moderate what is uploaded to CPAN? Or maybe "we" could have some kind of CPAN reality show where the loser modules are kicked out. (Ok, I'm getting carried away now. :})

Re:comprehensive

Aristotle on 2008-05-09T12:40:50

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 distributed it to at least one third party. They are thereafter under the conditions of your licence. If the licence you labelled your work with at upload time does not grant you the right to retroactively retract that self-same licence, then you cannot retroactively demand that the CPAN stop distributing it. (You can ask nicely, and maybe your request will be considered in the spirit of cooperation, but you have no right to demand it.)

That doesn’t make the module part of the public domain. The CPAN remains forever bound by the licence under which you uploaded the module.

I somewhat disagree

tsee on 2008-05-09T12:14:10

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 backpan is that as an organization which uses modules from CPAN, you gain independence of an author's decision to delete one or more of his modules' past versions. I'm all for keeping CPAN itself reasonably lean. but if there are potentially incompatible changes, some organizations really want to make sure they can fall back to the tried old version that's been running their service for the past decade.

Of course, you could just say that they're free to create a local backpan-like repository to ensure the described availability. But that's something that can be done (and is done, we have backpan) centrally much more conveniently.