Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [p2-dev] Shared installs and our EPP Packages

The thinking here is that the 'base' (the shared area) contains the base platform (say Helios).  Then, when you install a new bundle 'foo', this goes in your local area.  Now, your local file contains all the bundles from the base + foo.  When Eclipse launches, it checks that this is really the case (it checks that the shared is a subset of the local one).  I think there are two reasons for this.

1. The definition of 'shared' installs.  If each user could update the base then this is not really 'shared' anymore.  Some users have SR1, some have SR2, etc...

2. Consistency.  If a users updates some bundles in the shared area, and then the admin updates the base, what should we use now?

There could be other reasons for this too.


On Thu, Aug 12, 2010 at 6:11 AM, Zhu, Mengxin (Kane) <Kane.Zhu@xxxxxxxxxxxxx> wrote:
I'm wondering what's the intent of current mechanism(* part in Ian's
post) where picking up the bundles, share configuration or user

I think it should load the bundles from user configuration if it exists,
which is created and maintained by p2 as well.


From: p2-dev-bounces@xxxxxxxxxxx [mailto:p2-dev-bounces@xxxxxxxxxxx] On
Behalf Of Ian Bull
Sent: Thursday, August 12, 2010 4:47 AM
To: Eclipse Packaging Project; P2 developer discussions
Subject: [p2-dev] Shared installs and our EPP Packages

Hi everyone,

There have been a number of bugs opened regarding shared installs not
working [1,2,3,4,5,6].  While I don't know if they are all related, I
have tracked down a configuration problem with some EPP packages that is
causing this (at least it's causing it in some cases).  In both Eclipse
for Java Developers and the PHP package (I didn't check the others)
there are bundles listed in the file that are not in the p2
profile. When Eclipse is launched in a shared install scenario this
configuration problem will limit our ability to install additional
bundles. See below for the technical reasons*.

While shared installs were not very common in the past, they are
standard install on Windows 7 (when someone installs Eclipse in the
C:\program files directory).  So this means that anybody using an
affected Helios package on Windows 7 (installed in c:\program files\)
cannot install additional bundles using either the p2 UI or the MPC.

So this brings up a few questions.
1. Is this a known problem?
2. Do we want to address this for SR1?
3. How are the Helios packages created?  I created a helios package
manually using the director command**, and it was configured properly.
There must be additional steps that the helios epp builder is doing that
I'm not aware of.  There are also two p2 profiles in our EPP packages,
which seems odd to me.


* When we run in a shared install scenario, we create a
file from the p2 profile. When Eclipse is launched, our generated file is checked against the shared one, and if any
inconsistencies are found, we ignore ours and use the shared one.
However, the shared one is read only, and will never contain the
additional bundles.

**  I used the following director command when installing an EPP package
from the Helios repository:
./eclipse -application org.eclipse.equinox.p2.director
-destination /home/irbull/eclipse/eppinstall/
-profile eppProfile
-p2.os linux gtk
-p2.arch x86


R. Ian Bull | EclipseSource Victoria | +1 250 477 7484 |

p2-dev mailing list

R. Ian Bull | EclipseSource Victoria | +1 250 477 7484 |

Back to the top