RE: [p2-dev] updating a profile

[John Arthorne <John_Arthorne@xxxxxxxxxx>]

The simplest way to think of it is like
a garbage collector.  The set of IUs that are explicitly installed
are "roots". Adding or removing IUs in a provisioning plan will
cause those IUs to be added or removed from the root set.  The planner
then computes the transitive set of IUs to be installed from that root
set based on the IU's required capabilities. Removing a root may cause
only that single IU to be removed, or it may cause a whole set of IUs to
no longer be reachable and therefore uninstalled.  You were seeing
that behaviour because you were marking all IUs as "roots". You
would typically only install groups (i.e., features), or perhaps only a
single group that transitively includes other groups, and allow the downstream
IUs to be discovered and installed by the planner.

John

"Haigermoser, Helmut" <Helmut.Haigermoser@xxxxxxxxxxxxx>
Sent by: p2-dev-bounces@xxxxxxxxxxx

08/06/2008 04:52 AM

Please respond to
P2 developer discussions <p2-dev@xxxxxxxxxxx>

To	"P2 developer discussions" <p2-dev@xxxxxxxxxxx>
cc
Subject	RE: [p2-dev] updating a profile

Ciao Simon :)
Ah, that's the problem then, I was not aware of a special treatment of
IUs that only get installed for satisfaction of others,
my test case installs all IUs of a Repo, changing that to installing
only group-Ius made things work even without introducing the singleton
flag! :)

 I'm still interested in that flag as we seem to be able to make a
fundamental statement like "we only support a single version of an
IU in
our profile" using it...

Thanks for all the help guys,
Ciao, hh

-----Original Message-----
From: p2-dev-bounces@xxxxxxxxxxx [mailto:p2-dev-bounces@xxxxxxxxxxx] On
Behalf Of Simon Kaegi
Sent: Tuesday, August 05, 2008 9:33 PM
To: P2 developer discussions
Subject: RE: [p2-dev] updating a profile

That sounds strange.
Even if B 1.0.0 and C 1.0.0 are not singletons they should get
uninstalled along with A 1.0.0 so long as they were not explicitly
installed (e.g. they were only installed to satisfy A 1.0.0's
reuqirements).
The planner will remove all IUs that are not satisfying a depenency in
the tree of explicitly installed IUs.

Is it possible that B and C were explicitly installed or that they are
satisfying the dependencies of another IU in the installation?

-Simon


p2-dev-bounces@xxxxxxxxxxx wrote on 08/05/2008 03:08:49 PM:

> [image removed]
> 
> RE: [p2-dev] updating a profile
> 
> Schaefer, Doug
> 
> to:
> 
> P2 developer discussions
> 
> 08/05/2008 03:10 PM
> 
> Sent by:
> 
> p2-dev-bounces@xxxxxxxxxxx
> 
> Please respond to P2 developer discussions
> 
> I think that's it. Our IUs are not singletons and they probably 
> should. We'll give it another try and report back. Thanks Susan!
>  
> Cheers
> Doug (the Wind River night shift - Helmut's in Austria enjoying the
> evening right now :)
>  
> 
> From: p2-dev-bounces@xxxxxxxxxxx [mailto:p2-dev-bounces@xxxxxxxxxxx]
> On Behalf Of Susan Franklin McCourt
> Sent: Tuesday, August 05, 2008 3:00 PM
> To: P2 developer discussions
> Cc: p2-dev@xxxxxxxxxxx; p2-dev-bounces@xxxxxxxxxxx
> Subject: Re: [p2-dev] updating a profile

> Helmut, I'm assuming you had a typo and meant to say
> 
> Group A 1.0.1 -> IU B 1.0.1
> Group A 1.0.1 -> IU C 1.0.1  <not B>
> 
> It sounds like you are setting up the profile change request as 
> expected (similarly to what the UI does in the update wizard).
> 
> Can you clarify what you mean when you say that IU B 1.0.0 and IU
C 
> 1.0.0 are not uninstalled. Are you referring to the profile's view
of 
> the world or what's on disk?
> If you execute a query on the profile for all IU's, do you see them
in

> the list?
> 
> I think that whether IU B 1.0.0 and IU C 1.0.0 should be uninstalled
> depends on whether the IU is a singleton - 
> IInstallableUnit.setSingleton(boolean).
> If it is not a singleton, then I'm not sure that the director/ planner

> is that aggressive in removing the older versions simply because the
> newer version was brought in by an update. (Pascal could say for sure
> - he is on vacation right now).
> 
> If B and C are singletons, then it sounds like a bug that the IU's
are

> not uninstalled.
> If they are not singletons, then I think you would have to explicitly
> tell the planner to remove those IU's.
> 
> susan
> 
> 
> [image removed] "Haigermoser, Helmut" 
> <Helmut.Haigermoser@xxxxxxxxxxxxx>
> 

> 
> [image removed]
> 
> [image removed]
> "Haigermoser, Helmut" <Helmut.Haigermoser@xxxxxxxxxxxxx>
> Sent by: p2-dev-bounces@xxxxxxxxxxx
> 08/05/2008 09:32 AM
> Please respond to P2 developer discussions
> 
> [image removed]
> 
> To: <p2-dev@xxxxxxxxxxx>
> cc: 
> Subject: [p2-dev] updating a profile
> 
> 
> 
> Ciao Guys :)
> I'm having a little difficulty understanding updates to a profile,
can

> you please solve this mystery for me?
> 
> Here is my simple IU - structure:
> Group A 1.0.0 -> IU B 1.0.0
> Group A 1.0.0 -> IU C 1.0.0
> 
> Here is the available updates:
> Group A 1.0.1 -> IU B 1.0.1
> Group A 1.0.1 -> IU B 1.0.1
> 
> Here is what I'm doing:
> 1.) Run the UpdateChecker and wait for a notification
> 2.) Based on the UpdateEvent, create a ProfileChangeRequest:
> Add "Group A 1.0.1" to the "IUsToAdd" array of
the request Add "Group 
> A 1.0.0" to the "IUsToRemove" array of the request
Note that I don't 
> add the dependent IUs here, only the group
> 3.) Calculate a provisioning plan and execute it.
> 
> Now, here is what happens:
> Group A 1.0.1 gets installed
> IU A 1.0.1 gets installed
> IU B 1.0.1 gets installed
> Group A 1.0.0 gets uninstalled
> 
> You see? The problem is The IUs A and B, their original versions 1.0.0

> remain installed, even after a garbagecollector.runGC(IProfile), so
it

> looks like the dependencies are correctly resolved for the install
> phase but not for the uninstall phase. There is still the chance of
me

> having a bug in my own code, but could you try and explain the issue,
> maybe I'm using something in a terribly wrong way...
> TIA,
> Ciao, hh
> _______________________________________________
> p2-dev mailing list
> p2-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/p2-dev
> _______________________________________________
> p2-dev mailing list
> p2-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/p2-dev

_______________________________________________
p2-dev mailing list
p2-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/p2-dev