On Thu, Mar 11, 2010 at 10:28:09PM -0800, Chris Quenelle wrote: > The fundamental problem seems simple to me. You have python24 and python26 > and you want /usr/bin/python to find the "newest" one. It's a trivial > decision to make and update whenever you add or remove a package.
Verexec proposal on Stephen's blog describes a portion of metadata that's delivered by the package as part of your filesystem, but resolved by the runtime. This addresses the part of your concern where the package system delivers the "newest" version of Python, in whatever way you happen to define that. > Here's a scenario that requires a runtime solution. I've got a large system > I'm running or building. Deep inside the system is a perl script that > MUST run with an OLDer perl, but it's been coded to use /usr/bin/perl. > I need to override the version with an environment variable. This seems like a contrived case. If you know the script needs a particular version of Perl, why not change its #! to map to the version of perl you need directly? 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). -j _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
