Tom Mueller (pkg-discuss) wrote:
> What are the semantics supposed to be?
>
> I tried the following:
>
> pkg:/[EMAIL PROTECTED] is a simple package with just a set action
> pkg:/[EMAIL PROTECTED] is also a simple package with just a set action
> pkg:/[EMAIL PROTECTED] depends on pkg:/[EMAIL PROTECTED] (type=require)
>
> pkg:/[EMAIL PROTECTED] has the following:
> depend fmri=pkg:/[EMAIL PROTECTED] type=incorporate
> depend fmri=pkg:/[EMAIL PROTECTED] type=incorporate
>
> I'm trying to express here that [EMAIL PROTECTED] can only run with [EMAIL
> PROTECTED] and not [EMAIL PROTECTED]
>
> In an image, I install [EMAIL PROTECTED], [EMAIL PROTECTED] and [EMAIL
> PROTECTED] Everything fine so far.
>
> Then I install [EMAIL PROTECTED] and it allows me to do it. A "pkg
> image-update" also
> upgrades a to [EMAIL PROTECTED]
>
> So it appears that a is not being frozen at version 1. Is that what is
> supposed to happen?
>
> I'm also wondering about this extra package "i" that has the incorporate
> dependencies. Shouldn't a package that has a dependency on a specific
> version of another package actually express that dependency itself?
>
> I tried putting both an incorporate and require depend action for the
> same fmri in a single package. The publish worked, but when I tried to
> install that package I got the following error message:
>
> Creating Plan -client.py: install failed: ['Duplicate actions',
> [(('depend', 'pkg:/[EMAIL PROTECTED]'),
> set([<pkg.actions.depend.DependencyAction
> object at 0x84579cc>, <pkg.actions.depend.DependencyAction object at
> 0x845786c>]))]]
>
> In the test cases in t_upgrade.py, the incorporate dependencies are also
> in a separate package which then has to be explicitly installed. How are
> users supposed to know that they should have this extra package?
>
> Thanks.
> Tom
>
> P.S. We are planning for introducing updates into the Glassfish V3
> repositories, some of which introduce incompatible change that require
> multiple packages to be updated at the same time. I was hoping that we
> could use incorporations to force the updates to happen in this way.
>
Right now incorporations just specify a minimum dependency; this is a
missing
feature and will get fixed soon. We need a better dependency evaluation
mechanism that supports back-tracking to make this work correctly.
I'll look into the problem w/ the duplicate definitions.
Note that circular dependencies are legal; you may wish to do the following
for now:
base package has optional dependency on specified rev level of add-on pkgs
add-on pkgs have required dependency on minimum level of base package.
- Bart
--
Bart Smaalders Solaris Kernel Performance
[EMAIL PROTECTED] http://blogs.sun.com/barts
"You will contribute more with mercurial than with thunderbird."
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
