Chris's Wiki :: blog/solaris/OmniOSKYSTYProblem Commentshttps://utcc.utoronto.ca/~cks/space/blog/solaris/OmniOSKYSTYProblem?atomcommentsDWiki2014-01-14T20:39:59ZRecent comments in Chris's Wiki :: blog/solaris/OmniOSKYSTYProblem.From 31.151.153.51 on /blog/solaris/OmniOSKYSTYProblemtag:CSpace:blog/solaris/OmniOSKYSTYProblem:1655457b45dca0db767576ca0b48b4ca1dcd87b8From 31.151.153.51<div class="wikitext"><p>For normal users, KISTY is obviously a problem: most people do not know/cannot build their own software repositories containing custom versions of software.</p>
<p>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.</p>
<p>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.</p>
<p>It takes a bit of work, but once in place it is quite static really.</p>
<p>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 ;-)</p>
</div>2014-01-14T20:39:59Z