Tom Mueller wrote: > 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? >
What you're trying to do is to misuse incorporations to replace a feature we haven't implemented yet, called a freeze. You can simulate this with another incorporation, I believe. > (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.) Because of the code in make_install_plan, which applies constraints to the fmri. Suppose I wish to install package A. I need to determine if it is bound by any incorporations, and set the portion of the version specified by the incorporations(s). In general the code cannot currently evaluate all ramifications of the proposal prior to trying it; once we try something we continue on or fail as there is no backtracking implemented. This code will all change as we know we need a more sophisticated approach; we're experimenting w/ SAT solvers... Right now incorporations should not incorporate other incorporations, including themselves unless you're willing to un-install the outer incorporations manually while upgrading them. - 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
