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?

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).

>   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 :).
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss

Reply via email to