By EricReid-Oracle on Mar 25, 2014
We in Oracle Systems ISV Engineering work with Solaris. A lot. In doing so, we tend to 'push the envelope' in trying new things, and thinking 'out of the box', for our ISVs and ourselves.
When deploying a new Solaris 11.1 instance last week as an internal infrastructure server (LDoms and Zones and Oracle 11g, oh my!!), one of our engineers determined that the default version of Python that comes with Solaris had a few minor issues with one of our applications.
As we learned the hard way, you do not wish to replace the Python that comes with Solaris with an older version. No, Sir. Because, as some of us know, Solaris has made copious use of Python for a growing percentage of its userland infrastructure in the last few years. Solaris can't live without Python -- more specifically, the exact version of Python with which it ships.
What happens when you replace that Python installation with a reasonable-but-earlier version? Bad things. Very bad things. Your system won't boot next time you want it to -- it will whine and tell you it has a bunch of unhappy SMF services, and will then dump you out in Single-user Maintenance mode. All attempts to use pkg or most any other CLI tools to bring back the original Python instance fail, because of the Python mismatch.
We eventually sorted it all out, and thereby learned a hard lesson. By the way, multiple Python installations can co-exist in Solaris just fine -- just be very careful about all your PATHs, so that Solaris doesn't somehow end up using your second installation.