* Nicolas Williams <[email protected]> [2009-08-25 19:02]: > On Tue, Aug 25, 2009 at 11:27:11AM -0700, Stephen Hahn wrote: > > * Chris Quenelle <[email protected]> [2009-08-25 16:11]: > > > 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. > > Which is what verexec does. Suppose you want to deliver version Python, > so you'll have /usr/python/<version>/bin/python, and /usr/bin/python be > a copy of/link to verexec(1). Should there be a separate pkg for the > "shared" path? Or should the pkgs that deliver each version of Python > all have a shared action delivering the same /usr/bin/python?
Separate package, as described in the post. > Having verexec(1) allows you do go for the separate pkg to deliver the > verexec(1) links. But then you have an open set of dependencies for > that separate pkg. > > I.e., the packaging system designers have to choose between: > > a) a way to manage shared actions > b) a way to express the dependencies of a pkg that delivers a "shared" path > c) do nothing; a pkg that delivers a "shared" verexec link could be > installed even though no pkgs are installed that delivered the > versioned application. > > All three seem reasonable to me. In all cases there's a need for a > verexec(1). Hmm, okay. > > 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. > > (b) looks like a generalization of the problem to me. (a) is simple to > implement: provide a way to declare a path "shared" and allow pkgs to > share it provided that they all deliver exactly the same action for it. > (c) is simpler still :). verexec(1) has logic to identify (c). - Stephen -- [email protected] http://blogs.sun.com/sch/ _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
