You shouldn't mess with the base OS,

Huh? /usr/bin/perl is an installed application like any other and is not the OS. So, what you are telling me is that it is better to leave a broken Perl in place than replace it with one that works?

Let me give a really good example of why I'll put my own copy of /usr/bin/perl in place of one that is there already. Solaris 10 comes with a version of Perl. Unfortunately it is compiled with Sun's own liscenced compiler. If I just want to accept the list of CPAN modules that Sun has so graciously supplied then that's ok.

However, in this case our environment, which stores all user account information in LDAP needs to have Net::LDAP and friends installed on all the servers for some of our user administration tools to work. Since our LDAP servers are connected to via LDAPS and not clear text LDAP we need the whole family of SSL related modules compiled in as well.

None of those will work correctly if you try and compile them with a compiler other than Sun's compiler assuming we leave Sun's version of Perl in place.

Contractual and financial realities being what they are on that account we are not going to be having access to a Sun compiler anytime soon, so we use GCC.

who knows what that might break.

That's where proper engineering practices come into play. Anything we do in our production environment has already been done on test boxes. While we don't have the luxury of an official Sun compiler, we do have test boxes we can do things to before impacting production.

So, your argument of "don't mess with it" in this case doesn't hold much water. I would agree with your assesment if proper engineering wasn't done ahead of time and without a good understanding of the systems and applications involved.

I’ll throw my $.02 into the ring….

Solaris 8 on up ship with a /usr/bin/perl. Therefore by definition if you replace it you are “messing with the OS”.

Just because it does not meet your needs does not mean it is broken. It is the Perl that the OS vendor and those who develop for that platform expect to be there and that is what is important to keep in mind and that is why it should not be replaced.

Do you know what parts of the OS use the vendor supplied Perl? Do you know what additional applications use it? Do you know what will use it in the future? Catching one of these problems in test is good but it doesn’t change that you would have to do some re-engineering.

Do you make sure that SUNWpl5u (and the supporting packages) are uninstalled (or never installed)? Or do you leave the packages out there and just overwrite the files? If you leave the packages there then what do you do regarding patches? What do you do when upgrading the OS? What if the new OS has dependencies on /usr/bin/perl that the previous version did not?

Let’s talk about your test environment. Do you have a list of every script on your system that uses /usr/bin/perl? Do you specifically test these for compatibility as part of your testing process? Do you update your list? From your post it sounds like the answer to all of these is a negative. Wouldn’t proper engineering be to document everything that relies on /usr/bin/perl, keep that list up to date, and test everything that actively uses it?

Looking at a couple systems here it looks like /usr/bin/perl is used by Gnome, fibre monitoring tools such as SUNWstade, and some Internationalization tools. And here’s a big one -- SUN’s JES Directory Server, which is now included with Solaris (starting with one of the later Hardware Releases for Solaris 9 I believe). And that’s just from a quick look.

Anyway, I hope you get the idea (if nothing else that your decision can have unforeseen future ramifications).

Just because it does not meet your needs does not mean it is broken.

I'm sorry... but that smacks of "we know what's best for you." I beg to differ. If sometihng that is shipped with an OS doesn't meet my needs it is IMHO by definition broken.

I have a table saw in my workshop. Its table is only two feet wide. I regularly cut four foot by eight foot sheets of plywood on it. So I have feed extensions that I've added to the mix to help with that.

Further, that table saw came with a rip blade that is not suited to cutting plywood. Do I leave the rip blade in there assuming the saw manufacturer knows what's best for me and deal with the mess or do I buy a blade more suited to cutting plywood and install it? Geez.. by your definition I'm messing with the design of the table saw. I won't even get into the modifications I've made to the saw itself including the much improved blade guide I added. (Thank you Workbench magazine!)

Do you make sure that SUNWpl5u (and the supporting packages) are uninstalled (or never installed)?

As a matter of fact the latter. SUNWpl5u is specifically left out of our builds because of the issues I've already outlined.

Do you specifically test these for compatibility as part of your testing process? Do you update your list? From your post it sounds like the answer to all of these is a negative. Wouldn’t proper engineering be to document everything that relies on /usr/bin/perl, keep that list up to date, and test everything that actively uses it?

What part of my comments made you think that things aren't tracked?

You mention Sun's JES Directory server. Not used in my shop since we used OpenLDAP for the same thing. One of the reasons I've already mentioned for doing what I do.

Fiber monitoring tools? Again. Not an issue in our shop. However it was in a previous shop that I worked for and our version of Perl that we packaged worked fine.

Do you have a list of every script on your system that uses /usr/bin/perl?

Considering that my shop is the only one doing scripting in Perl? That's a safe assumption. Since 2001 when I joined this shop we have yet to run into an issue like you are describing. Our testing is rather thorough so we must be doing something right.

Anyway, I hope you get the idea (if nothing else that your decision can have unforeseen future ramifications).

Which is why we test. And test again. In fact we have one system in particular dedicated to that end. It is rebuilt every week automatically and the latest patches (along with the latest versions of our internal packages) applied to it. This is how we detect bad patches (something Sun has excelled at producing lately for Solaris 10) before they are applied to our production environment.

---

Peter L. Berghold -- Unix Professional
Peter -at- Berghold -dot- Net; AOL IM redcowdawg Yahoo IM: blue_cowdawg