On 03/12/10 09:28, Nicolas Williams wrote:
On Fri, Mar 12, 2010 at 12:53:34AM -0800, [email protected] wrote:
The primary problem this solves is ensuring that /usr/bin/perl always
points to the newest version of perl. However, this also allows you to
solve the case where your application needs perl 5.6, and another
application needs perl 5.8, but you need intermediate versions of these
as well as the latest. If you tell verexec to launch /usr/bin/perl5.6
and /usr/bin/perl5.8, it'll find 5.6.2 and 5.8.9 if they are installed.
If you want to leave 5.8.4 installed for testing you can do that, but
any scripts that specify 5.8 without any further refinement get 5.8.9
(latest).
The verexec env var override is not really a workable solution for that.
When you know you need a specific version of<fill in the blank> then
invoke that version directly.
Given that I now see Chris' point. verexec(1) is really just a very
simple run-time mechanism for managing install-time version selection.
It could be simpler -just a hardlink- if IPS had an install-time version
selection feature instead.
No.
While we may be able to insist that all Solaris components contain an
versioned path to the executable, it is not practical to insist that
all software in the world do so.
As a result, having an environment variable available to select an
alternate version of python, perl, etc. makes a lot of sense.
- Bart
--
Bart Smaalders Solaris Kernel Performance
[email protected] http://blogs.sun.com/barts
"You will contribute more with mercurial than with thunderbird."
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
