[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [p2-dev] updating a profile


Yes, singleton means only one version with that id can be installed in the profile at a time. Assuming your IUs represent OSGi bundles, then the "singleton" flag on the IU should be the same as the singleton directive in the bundle manifest (the singleton:=true directive on the Bundle-SymbolicName header). In any case, the singleton flag wasn't your problem here, as discussed in the other thread.

John



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

08/06/2008 04:32 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 Susan :)
Thanks for your swift answers!
It's great to hear that what I'm doing is within the expected workflows.
:)
The problem below was uncovered by a unit tests I created before
tackling the real work, a simple
generation-installation-generation-update
test that will try to apply updates to a profile and check that profile
for the expected IUs. One test in particular went wrong where I tried to
update a single group, A, and expected the old version of the group and
the required Ius to be gone from the profile afterwards...

Yes, your assumption was correct about that type, sorry for that! :(

So, singleton means only one version can be installed in a profile at a
time? Guess that's one way to solve this issue,
is there any risk in changing this flag now, side effects maybe?

Thanks so far! :)
Ciao, hh

-----Original Message-----
From: p2-dev-bounces@xxxxxxxxxxx [mailto:p2-dev-bounces@xxxxxxxxxxx] On
Behalf Of Susan Franklin McCourt
Sent: Tuesday, August 05, 2008 9: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


Inactive hide details for "Haigermoser, Helmut"
<Helmut.Haigermoser@xxxxxxxxxxxxx>"Haigermoser, Helmut"
<Helmut.Haigermoser@xxxxxxxxxxxxx>




               


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

                                                                   08/05/2008 09:32 AM
                                                                   Please respond to P2 developer
discussions



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