[email protected] wrote: > The point that Stephen made was that encoding all of the knowledge about how > to reconfigure your system to get the latest version of a particular > language runtime lead to enourmous and hard to maintain install scripts.
If Stephen wants to claim that verexec is a replacement for lots of complicated goop in the postinstall script, then I would need to know what that goop is before I can form an opinion about whether his proposal does the job he wants it to do. My assumption is that the complicated goop could also have been solved by building an explicit strategy into the previous generation of packaging tools, and using that strategy. But it's hard to say without more details. 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. 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. You need the script version of VEREXEC to do that. My question is: Is that problem one of the things we need to solve? If so, can someone supply real-world examples of how this scenario has bitten people? --chris _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
