So the effect that you want is to be able to have multiple different versions of a program installed at the same time, and ensure that the "correct" version gets executed by default without the user needing to customize their search path. One scenario where this is required is when several layers of scripts end up setting PATH and running other scripts, and eventually running /usr/bin/prog. The user may not be directly running "prog".
How does the verexec solution compare with a package-based solution? Start with the basic assumption that we have two IPS packages. One called prog13 (version 1.3) and one called prog14 (version 1.4). They install into /usr/prog13 and /usr/prog14. When both are installed /usr/bin/prog finds /usr/prog14 (because the version is "larger"), and if the admin uninstalls prog14, then /usr/bin/prog should automatically find /usr/prog13/bin/prog. So far so good. But isn't it straightforward to implement the same feature when the software is installed/uninstalled? The path /usr/bin/prog would need to be treated specially by all the packages that share it, and the pkg command would need to maintain that symlink according to the desired rules. One down side is that you can't control it with an environment variable, but it doesn't seem like the environment variable control is really the reason for the verexec solution. (?) So what am I missing here? --chris Stephen Hahn wrote: > Please read > > http://blogs.sun.com/sch/entry/verexec_1_a_simple_execute > > for some background, and then review > > http://cr.opensolaris.org/~sch/on-verexec/ > > I'm debating implementing some of the refinements mentioned in the > blog entry, as well as providing manual pages for both verexec(1) and > isaexec(1). > > Thanks > Stephen > _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
