| Re: [equinox-dev] [prov] Comments on wiki "Equinox p2 Shared Install Plan" |
Hi, On Mon, 2007-12-17 at 13:44 -0600, James D Miles wrote: > If I was looking at this from the perspective of only RPM for the SDK, > you would likely be close enough. Sorry if it appears that's how I'm looking at it. I'm trying hard not to. Your comments are helping. And I'm definitely not looking at it only from the SDK POV. > >> 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. I guess I'm just considering sane defaults here. Are we closing the door on more exotic 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? I envision shared stuff being in the shared bundles.txt and user-specific stuff being the user bundles.txt. They don't overlap. > >> 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. Sure, but I don't see how this is entirely related. Why can't the admin just use the admin UI or something? What's the advantage of a shared install if everyone's got a unique installation? > >> 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. That's unfortunate :( . > 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. I'm having trouble understanding what you're trying to say here. You don't want to run certain phases and I do. What's the problem? > 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. Why will the properties be in an RPM? We're (the Linux distros) not providing RPMs of workspaces -- just the runnable bits. > Are you saying that an admin will only upgrade the shared install > through rpm and the update UI can not be used? The admin UI *can* be used, but in the Linux distribution case, I envision people will largely use their packages. That's what people (including me) want to do :) . > >> 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. It's harder for a few reasons: 1) user home directories shouldn't (and sometimes can't) be touched by an RPM installation 2) the order of laying down new files and deleting old files and trigger scripts (ex. %post, %postun of old and new) doesn't really lend itself to profile modification. If one of these scripts fails, it'll kill the entire transaction -- including a fresh installation. If we try to trap failures, we may end up with a non-runnable state. I want to keep things as simple as possible for package-based installations where we just lay down the bits and the runtimes does The Right Thing. > 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. I was talking about root IUs with Pascal and he thinks we can use local metadata repos for this. Andrew
Attachment:
signature.asc
Description: This is a digitally signed message part