Ok, after some thought, and fielding a LOT of perl questions on #debian, I've come up with a more workable idea which gives us much better handling for the next time something like this happens..
Rename perl to perl5.005, version 02-2 or such.. Then use the alternatives setup to decide which perl gets run when you try to use just 'perl'.. At that point packages which are NOT subject to binary compatibility issues can depend on perl5, and those which are can depend on perl5.005, etc.. This allows us to both handle future perl upgrades cleanly, and allows us to maintain more then one version of perl at any given time.. Any comments? Zephaniah E, Hull.. On Thu, Oct 08, 1998 at 09:57:36AM -0400, Dan Jacobowitz wrote: > > Le Thu, Oct 08, 1998 at 02:31:40AM -0700, Darren/Torin/Who Ever... écrivait: > > > I do worry about what this might break as well. Another option would be > > > to have /usr/lib/perl5/debian(/$arch)? be the first element of @INC and > > > leave /usr/lib/perl5/$version(/$arch)? there with only the Perl > > > installed files. I'll ask on p5p if this will break things. > > My question is, why are we so intent on removing the versioned > component even though we have lost binary compatibility? I understand > that it requires some packaging changes, but the packaging can usually > be easily rewritten to work for any version (use perl5/5.*/, etc.). > > Dan > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] >
pgpk4oO1Le4IK.pgp
Description: PGP signature
