The problem with OmniOS's 'build your own' view for Perl and Python

January 14, 2014

A commentator on my entry on Python 2's lifetime mentioned that OmniOS has adopted a principle called KYSTY. To simplify, the core of this principle is that you are not really supposed to use the OmniOS versions of things for your applications. To quote them:

We purposefully ship only what we need to build and run the OS. In many cases, these are not the most recent versions. Except in the most basic circumstance, you should not use these things in your app stack. At best, their versions are stagnant; at worst, they may go away entirely as the OS components they exist for are rewritten or removed.

There are two problems with this when it comes to things like Perl and Python. The first is a variant of the problem with compiling your own version of Python 3; requiring people to build or get their own versions of Perl and Python makes writing small utilities in those more expensive. In practice many people aren't going to do that and will instead use the system versions, with various consequences.

The larger problem is what this does to script portability in heterogenous environments. Like it or not, there is a de facto Unix standard about where to find at least Perl and Python and that is at well known names in /usr/bin. Making those names not work right in favour of, say, /opt/csw/bin/perl means that scripts that work on OmniOS won't work on other machines and vice versa; each side's scripts will have a #! line that points to something that is either wrong or not there at all. This is not doing people any favours (and yes, some people still run heterogenous environments with shared scripts).

(The #!/usr/bin/env hack doesn't help because you can't count on optional add-on directories being in $PATH in all cases and all contexts. In fact I tend to think that it is a great recipe for real problems but that's another rant.)

The OmniOS approach is arguably sensible for large applications with their own deployment infrastructure and workable if OmniOS is by itself in a homogenous environment. It is not appealing if OmniOS is in a heterogenous environment and what you're writing is glue scripts and utilities and so on.

If OmniOS wants to take KYSTY seriously it needs to not claim the names /usr/bin/perl, /usr/bin/python, and so on. OmniOS Perl and Python scripts should use a private OmniOS name for the OmniOS versions of those and leave the official public names to sysadmins to set up however they want (or not set up at all, so that you know that all of your scripts have to be using your specific version of whatever).


Comments on this page:

From 31.151.153.51 at 2014-01-14 15:39:59:

For normal users, KISTY is obviously a problem: most people do not know/cannot build their own software repositories containing custom versions of software.

Omnios is not for normal users, but for storage administrators familiar with linux (at least) and most probably, solaris. For those admins, maintaining custom versions of software packages should not be a problem. Inconvenient at most, but certainly doable.

We have been deploying custom perls for ages using cfengine and rsync, adding libraries or upgrading the whole stack is very easy, as is maintaining dev/staging/prod versions of it. Cross compiling is trivial at least with i686/amd64. No experience with other architectures, but in these times of virtual machines, having a build vm for your target architecture should not be a problem. You then just deploy the right compiled dir to the different architectures with the same path to the binary on all of them, shebang problem solved.

It takes a bit of work, but once in place it is quite static really.

Why should Omnios not claim the paths in /usr/bin/ for perl or python? It's their build, so it's up to them. IMHO you got your conclusion backwards, but if you want to decide what goes in /usr/bin/{perl,python} it's your system, you get to keep all the pieces when stuff breaks ;-)

Written on 14 January 2014.
« Sadly, we're moving away from Red Hat Enterprise Linux
Real support periods versus nominal official ones »

Page tools: View Source, View Normal, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Tue Jan 14 00:13:17 2014
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.