| Re: [equinox-dev] [prov] Comments on wiki "Equinox p2 Shared Install Plan" |
If I was looking at this from the perspective of only RPM for the SDK, you would likely be close enough.
>> 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).
That is ok as a default maybe. However this decision should be deferred until runtime. A user might want to run multiple instances with multiple configurations.
>> 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?
Ahh. That was a bad paraphrase of what I thought you indicated. So if you load the shared bundles.txt how do you get a user's bundle.txt? How long do you use the shared?
>> 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.
One size does not fit all. One user might want bundle A from ABC and another user might want bundle A from XYZ. The admin might want to provision a limited functionality product for user A. And he might want to provision prototype stuff for user B. This can all be driven through the profiles/IUs.
>> 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.
It is nice that you can still do that. That is far from ideal for us. We have to be able to maintain our products in many ways, rpm being just one. For instance the admin wants to upgrade a few bundles in the shared install. One of the bundles may need the libpath modified to point to the new native dll. If a bundle and IU can manage itself it is a lot easier. We also have to support many platforms besides RedHat. By containing/managing bundle artifacts on a bundle basis we are much more efficient. Only the bundle developer needs to work on the change.
If the user is running multiple workspaces where one workspace uses jdk A and one uses jdk B. It will be hard to manage the property differences in an rpm.
Are you saying that an admin will only upgrade the shared install through rpm and the update UI can not be used?
>> 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.
I am not sure why it should be harder. One way or another we have to have a profile/profile(s) that represents the configuration that the user will run with. So after CDT is installed it seems that we would still need profiles and rootIUs that represent the installation or we will not be able to make decisions about updates. If we start driving from both ends it has to be harder.
Andrew Overholt <overholt@xxxxxxxxxx>
Sent by: equinox-dev-bounces@xxxxxxxxxxx 12/17/2007 12:00 PM
|
|
Attachment:
signature.asc
Description: Binary data