* Chris Quenelle <[email protected]> [2009-08-25 16:11]: > 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?
Actually, we've seen that it is not straightforward. See, for instance, the Java preremove and postinstall scripts over the years. > 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. Oh, I see--the suggestion is to have the package system treat this class of shared resource specially? My initial feeling was to keep this sort of behaviour outside of packaging, because we use it relatively rarely. If we could identify a bunch of similar resources--not necessarily version-driven--then perhaps we can revisit. Having multiply owned objects will likely bring in a bunch of policy/configuration, which I was trying to avoid. For instance, how would N packages declare that /usr/bin/[target] is shared? What if a package fails to make this declaration, and delivers [target] as a regular file? (These situations can happen with the current system, but are clearly errors, as multiple delivery of files is disallowed. If we relax that, then error analysis becomes more complex--which is fine, if we need this feature.) > 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? My assessment is that we would have to spend a lot of time generalizing a problem that, for the specific case of versioned executables, seems to have a simple solution. Without examples of other shared resources, addressing that general problem seems unnecessary. - Stephen _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
