Beefy Boxes and Bandwidth Generously Provided by pair Networks
No such thing as a small change
 
PerlMonks  

Re^7: Apple says sorry for Mac Perl breakage (sort @INC)

by merlyn (Sage)
on Apr 01, 2009 at 04:50 UTC ( [id://754625]=note: print w/replies, xml ) Need Help??


in reply to Re^6: Apple says sorry for Mac Perl breakage (sort @INC)
in thread Apple says sorry for Mac Perl breakage

Hah!! And the current situation Apple and Mac users currently find themselves in is so much better?
Nope, just saying why your so-called "solution" isn't much better. :)

Replies are listed 'Best First'.
Re^8: Apple says sorry for Mac Perl breakage (sort @INC)
by Argel (Prior) on Apr 01, 2009 at 19:52 UTC
    Hmm, let me clarify. You know how some third-party apps ship with their own version of Perl (or Java)? Well, I think that's what should be done for operating system related tasks. A special Perl dedicated to that that can be kept clean and pure as possible. And then there should be a Perl on the system meant for more general use. Right now most people, including sysadmins, that I see just use the Perl provided in the distro. Some of these are people just running it at home, or do not have a lot of sysadmin experience. So in effect it is fostering bad habits. I see people even here at work that I consider to be good SysAdmins doing this. And it can be hard to argue against because it's one of those common sense things once you have enough experience. So if the OS vendors (e.g. Red Hat) started doing something like what I suggest above then that would become a Best Practice.

    Elda Taluta; Sarks Sark; Ark Arks

      When a third-party app ships their own version of Perl (or Java), the third-party is responsible for maintaining it, not the sysadmin. The reason sysadmins just use the Perl provided in the distro is because they know (from experience) that maintaining more than one version is a headache. Maintaining more than one version of anything (at the same time) is a headache. So you can either use the distro provided Perl (and let the OS vendor maintain it), or you can throw caution to the wind and replace it with with your own (and then you the sysadmin must maintain it). There are pros and cons to each and the decision to go one way or another will have a lot to do with the sysadmin's experience. But intentionally running multiple versions of Perl in a production environment is fostering bad habits (IMO).

        Just like the sysadmin is responsible for patching the system. With Red Hat's Satellite Server, apt-get, etc. having two different Perl's is not that difficult. The reason you think it is is because you are thinking of a scenario where you have to manually install the second Perl. The point is that the vendor/distro has to support multiple Perls, which is much easier (more QA, less people duplicating work, etc.). This very thread shows why it is better to have two. What is a bad idea is having OS scripts, third party vendor scripts, etc. relying on the same Perl that people are making changes to.

        Elda Taluta; Sarks Sark; Ark Arks

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://754625]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others scrutinizing the Monastery: (5)
As of 2024-03-28 17:42 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found