[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [equinox-dev] [prov] Comments on wiki "Equinox p2 Shared Install Plan"


On Mon, 2007-12-17 at 11:36 -0600, James D Miles wrote:
> bundles.txt stored in user home. 
> YES. I would change that to stored in users workspace or preferable
> user's configuration space.

Yes, configuration space is more accurate.  I just meant the user's
writable location (I'm thinking something like ~/.eclipse/p2).

> If bundles.txt is missing from the user's workspace then it needs to
> be populated with the shared bundles.txt. 

Why can't it just run from the shared bundles.txt?

> If you want to populate the user's bundle.txt with sdk in shared
> install then in can be driven as a root IU or profile. However this is
> a policy decision and should not be hard-wired as always happening.

I don't know what you mean here.

>  The act of provisioning the bundles also allows for the
> unfolding/customizing of additional artifacts related to specific
> bundles. An example of additional work would be creating user ICONs,
> setting environmental variables.
> What we are really talking about is running only a configuration phase
> to get the user's bundle.txt up to the latest. The phases collect, and
> install are not wanted. 

This is not ideal for the Linux distribution case.  We want things to be
completely ready to go after the user installs the packages.  .desktop
files and other metadata is just shipped in the package and put in the
right place upon installation so there's no need for additional
configuration in this case.

> Materialize profile from running bundles.txt
> I am suggesting it is better to materialize bundles.txt from the
> profile.

It's difficult and fragile to do profile manipulation with headless
package installation.  I'm specifically talking about the installation
of additional bundles here:  CDT, Mylyn, etc.  Pascal mentioned that he
has some in-progress code that will allow the materialization of
bundles.txt from the running instance and a set of root IUs.

Thanks for the comments,


Attachment: signature.asc
Description: This is a digitally signed message part