Bug 229342

Comment 1 Pascal Rapicault 2008-04-29 16:55:53 EDT

There are really two sub problems:
1) coming up when the base as changed
2) doing the reconciliation

For 3.4 now let's focus on issue #1 such that if the based changed the user can come back up without doing anything crazy.

Comment 2 Simon Kaegi 2008-05-09 00:09:55 EDT

Created attachment 99419 [details]
patch in progress

...still in progress. This patch shows the approach and works but will still need refinement.
Note: I'm setting the users config.ini to contain just...
osgi.sharedConfiguration.area=file\:configuration/

This is to avoid version problems for the framework and simple configurator while work on cascading config.ini values proceeds.

Comment 3 Pascal Rapicault 2008-05-09 09:41:19 EDT

Created attachment 99456 [details]
Patch

This patch causes the config.ini of the shared install to only contain the values that differ from the base config.ini.

Comment 4 Pascal Rapicault 2008-05-09 09:42:01 EDT

Created attachment 99457 [details]
Compiled version of fwk admin

Comment 5 Simon Kaegi 2008-05-09 10:56:14 EDT

(In reply to comment #3)
> Created an attachment (id=99456) [details]
> Patch
> This patch causes the config.ini of the shared install to only contain the
> values that differ from the base config.ini.

Thanks Pascal that works for my test case.

Comment 6 Pascal Rapicault 2008-05-09 13:49:59 EDT

Overall the patch looks good and we should get it out the door so that Andrew and others can try it. Before that a few things need to be addressed / answered:
- What is the PROP_RESOLVE property for (see line 189 of SurrogateProfileHandler userProfile.setProperty(PROP_RESOLVE, Boolean.TRUE.toString());
- Can't IProfile.available() be implemented by overriding the query() method?
- SurrogatePRofileHandler should reuse the IUProfilePropertyQuery instead of implementing the queries.

Simon, did you had a chance to look at my equinox fwk admin patch?

Comment 7 Simon Kaegi 2008-05-09 15:05:03 EDT

Verbal +1 from Pascal.

Updating what we discussed...

> Simon, did you had a chance to look at my equinox fwk admin patch?
I did -- looks good.

PROP_RESOLVE is used to signal the reconciler that it should create and execute a plan that will remove this property from the Profile but also cause expansion of the new install roots added by the SurrogateHandler. This flag is only added if there are non-base roots in the profile to prevent spurious expansion of the profile in the case where a user has done no other installation of software.

The difference between query() and available()...
"query" = what IUs are installed in the profile
"available" = what IUs must be available to the planner when creating a plan. This is used in the read-only case where the user profile contains only the "roots" but the metadata from the shared profile is made available so that we can perform a valid expansion of the roots should the user install new software.
"available" is possibly redundant if we can expose the shared profile as a metadata repository however this is a 3.5 thing.

The Queries in SurrogateProfileHandler can be implemented in terms of IUProfilePropertyQuery however this class needs to be moved first. I'll open a separate bug for this.