Bart,
I tried to explain the useful purpose that this serves in the paragraph
starting with "The idea here..." below. Let me try to explain again
using JSF (the JavaServer Faces add-on for GlassFish) as an example.
JSF has had two major release levels, 1 and 2. There are some
incompatibilities between these major versions such that a deployer of
the application server needs to control which version they are on. If
already on version 1, any updates to version 1 (1.1, 1.2, etc.) should
be applied automatically via image-update and the GUI should offer those
updates in the updates panel. The switch to version 2 needs to be an
explicit choice (sort of like installing a new addon). Once that choice
is made, any updates to version 2 should be applied as with version 1.
Ideally, the installation of version 2 should just be "pkg install [EMAIL PROTECTED]".
You might ask, why not have two different packages (jsf1 and jsf2). The
answer is that both versions cannot be installed at the same time in the
app server; you have to choose one or the other. If we had exclude
dependencies, then maybe this would be a case for that.
It seems to me that an incorporate dependency is exactly what is needed
for declaring this relationship between packages. This also achieves a
useful purpose, as described above.
Since this behavior worked before, we used this in the GFv3 Prelude
release that has just been made available. Fortunately, there is a
work-around in that the user can uninstall [EMAIL PROTECTED] and then install [EMAIL PROTECTED],
so this is not a show stopper issue.
At this point, I'd like to understand if this is supposed to work,
theoretically. And if I can find a fix for this, would this be accepted?
(I'm actually wondering why the code in ConstraintSet.start_loading
doesn't remove the constraint from the previous version when this
upgrade is attempted.)
Thanks.
Tom
Bart Smaalders wrote:
Tom Mueller (pkg-discuss) wrote:
Bart,
With the new incorporation logic in place, I'm seeing some new
behavior; is this expected?
Consider these packages:
[EMAIL PROTECTED] has in its manifest:
depend fmri=pkg:/[EMAIL PROTECTED] type=incorporate
[EMAIL PROTECTED] has:
depend fmri=pkg:/[EMAIL PROTECTED] type=incorporate
[EMAIL PROTECTED] has:
depend fmri=pkg:/[EMAIL PROTECTED] type=incorporate
The idea here is that when [EMAIL PROTECTED] is installed, an image-update
should bring it up to the 1.1 level. And future updates along the
1.x line will also be brought in with an image-update. If the user
wants to go to the 2.x level, they do a "pkg install [EMAIL PROTECTED]". This
then brings in the 2.0 version, and image-updates from that point
will bring in later versions of 2.0.
Before the recent incorporation changes, this worked as described.
With the changes, the image-update part works as expected, but the
upgrade to the 2.0 version is producing the following error:
$ pkg install [EMAIL PROTECTED]
Creating Plan -
pkg: the following package(s) violated constraints:
Package pkg:/[EMAIL PROTECTED],5.11 conflicts with constraint in installed
pkg:/jsf:
Pkg jsf: Optional min_version: 1,5.11 max version:
1,5.11 defined by: pkg:/jsf
Is this expected?
It would seem that the constraints that are defined by the packages
that one is explicitly trying to update should be ignored.
Before, incorporations only implemented a minimum constraint. They
now correctly the fmri at the specified level....
However, we don't yet have full back tracking support, and the
evaluation of complex incorporations is likely to have issues.
Making the following sorts of packages:
> [EMAIL PROTECTED] has:
> depend fmri=pkg:/[EMAIL PROTECTED] type=incorporate
is not likely to work. A package that specifies that it's own version
must be a less specific version of itself makes the upgrade logic
difficult, and achieves no useful purpose Don't do that.
- Bart
begin:vcard
fn:Tom Mueller
n:Mueller;Tom
org:Sun Microsystems, Inc.;Update Center Software
adr:;;21915 Hillandale Dr;Elkhorn;NE;68022;USA
email;internet:[EMAIL PROTECTED]
title:Senior Staff Engineer
tel;work:877-250-4011
tel;fax:877-250-4011
tel;home:402-916-9943
x-mozilla-html:TRUE
version:2.1
end:vcard
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
