Re^2: Sysadmin questions on efficient installation of new Perl versions

1) I don't keep them all, but I have had trepidation about removing them when I am not sure WHY perl creates a complete new directory structure for each update. If it is completely safe to remove them, then why is it not safe for the update to install into the same directory?

2) You have it backwards. The problem is keeping all addons and modules installed when updating perl. Again, if it is safe to just mv everything, then why does perl install into a completely new directory structure?

Comment on Re^2: Sysadmin questions on efficient installation of new Perl versions

Replies are listed 'Best First'.
Re^3: Sysadmin questions on efficient installation of new Perl versions by mpeters (Chaplain) on Jan 21, 2005 at 22:34 UTC
1) Perl creates a new directory because not every version (or subversion) is binary compatible. This means that if you had installed any perl libs that used XS (C code) they would not be guaranteed to work with a different version of perl than the one they were compiled against. So Perl avoids these problems by creating a different directory so that multiple perls can exist on the same system. 2) AFAIK it is not completely safe to just mv the directories. Only if you know that they are pure perl should you risk it. Even then you won't know that the old module passes it's test suite under your new version of Perl.	[reply]
Re^3: Sysadmin questions on efficient installation of new Perl versions by renz (Scribe) on Jan 21, 2005 at 21:22 UTC
AFAIK, you only need one distribution of perl. I never keep old distros. I am not aware of the logic behind the directory structures for each new release, but I understand your distress. I don't think it is a matter of it being inherently unsafe to install to the same directory as much as it is that it prevents you from doing something really stupid, like maybe overwriting perl5 directory with perl4. Shrug. God only knows how that would accidentally happen, but in a short time on this planet I have seen a lot of crap that mathematically shouldn't have happened but did anyway. Anyway, I always move my modules, but I imagine that I have a significantly smaller number installed than you do, which is why making a bundle is such a good alternative to remembering each one installed. I don't see why it would be a problem. Anyone with a clearer explanation out there? /renz. "I often wonder if I really need all of these bones." --Sean Stolon.	[reply]
Re^4: Sysadmin questions on efficient installation of new Perl versions by mpeters (Chaplain) on Jan 21, 2005 at 22:38 UTC
There may be some reasons to keep older versions of perl lying around (older code that uses it, other libs compiled against it, etc). But I can definitely think of one reason to have more than one instance of perl on the same system even if they are of the same version. If you are trying to run mod_perl 1.x and mod_perl 2.x on the same machine I would almost emphatically recommend using two different instances of perl since you will have some modules with the same name (Apache::Request for example) that are completely different versions (meaning A::R 1.x will not work with mod_perl 2.x and vice versa).	[reply]