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. I don't mind the verexec(1). I can see that the IPS functionality that we'd need to avoid verexec(1) is almost certainly nowhere near as trivial as verexec(1). We can optimize verexec away later. Nico -- _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
