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

You make a good point about not using the user's module updates for the system tools. However, the system tools should normally be run as a superuser account, which shouldn't normally be used for day-to-day production programming.

Beyond that, even system-wide system-specific module upgrades shouldn't change anything for OS distro utilities that use the modules. If they're packaging perl, the Perl modules, and packaging the apps that depend upon those modules, then the packagers of those dependent apps should have no problem knowing and using the exact paths to the original versions. There's even an optional vendor_perl directory one can configure during the perl build that's just like the site_perl directory. Mandriva uses it, so why not Apple?

I can understand the hesitation for a company that sells products based on "it just works" to bundle the latest and greatest software in their distribution all the time. I'm sure they only use things they're had time to test as units and in integration. While being on the cutting edge is great for some, when you're selling boxes to lots of people and want few support issues, you usually do stay back a few releases for stability and testing reasons.

  • Comment on Re^3: Apple says sorry for Mac Perl breakage (sort @INC)

Replies are listed 'Best First'.
Re^4: Apple says sorry for Mac Perl breakage (sort @INC)
by Argel (Prior) on Mar 31, 2009 at 23:38 UTC
    This is simply a result of distros (Linux, *BSD, etc.) and Operating System vendors encouraging bad practices. There should really be two installations of Perl. One for the OS/sysadmins to use and one for developers/general use.

    Elda Taluta; Sarks Sark; Ark Arks
[reply]
      There should really be two installations of Perl. One for the OS/sysadmins to use and one for developers/general use.
      "hey jim... did you install CGI::Prototype like I asked?"

      "yeah".

      "I don't think you did it right... web apps still not launching."

      "no, really... here's my 'sudo cpan' command showing what got done."

      "weird... wonder why the web app isn't seeing it."

      See... that's not much better.

      -- Randal L. Schwartz, Perl hacker

[reply]
        Hah!! And the current situation Apple and Mac users currently find themselves in is so much better? This thread shoots your comment out of the water!! :-)

        Sysadmins should know how to keep track of the two. Developers likely not, but then the sysadmins should be helping them out by setting appropriate PATH related environment variables, etc. And really talented developers will pick up the necessary sysadmin skills. So really all you have done is point out that you can't fix stupid.

        That still doesn't change that there should be a clean Perl installation that the OS, third party vendors, etc. can use safely and another installation that the developers can have some fun with (i.e. if they break t it doesn't break the Perl used by OS scripts, vendor scripts, etc.).

        I mean, if you replace the Bourne Shell binary with the Bash binary on a Solaris system wouldn't you expect to break some things? Then why do you think it's okay to make changes to the OS's Perl installation?

        There are conflicting goals at play: a stable, clean Perl installation that the OS, vendors, etc. can rely on and the need for a Perl installation that can be enhanced and upgraded. If you have two (or more) Perl installations then you can have your cake and eat it to. Otherwise, you have to pick.

        [ Of course that's ignoring that the cake is a lie! ;-) ]

        Elda Taluta; Sarks Sark; Ark Arks
[reply]
      I'm sorry, but was this intended to be a replay to my node? I made four very specific points, none of which you specifically addressed.

      Having a separate installation that is installed by the user for his own use is a good idea (and a best practice, really), but it is not strictly necessary if perl is installed and configured completely correctly.

      It's a quite bad idea, IMO, to provide two separate installations out of the box as merlyn points out so humorously. A savvy user should install one's own. A less savvy user either won't mess with the system perl or shouldn't.

[reply]

In Section Perl News