[
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"
|
Hi,
James D Miles wrote:
> 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?
Sorry, I don't understand your question.
You said that decisions about where in a user's home directory stuff
should be stored should be deferred until runtime. I don't see why
can't provide sane defaults (like ~/.eclipse or something) but allow
configurability for more exotic policy decisions. Are we somehow
stopping your products from making this decision at runtime? I assumed
it would just be ~/.<productid> or something if that's what you mean by
"decide at runtime."
> > >> 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?
- one image for supported bundles or supported profiles.
- don't need a completely new image just because someone needs slight
variation.
If you allow the admin to use the admin UI and modify the rpm artifacts
does that cause a problem?
Yes, since it invalidates the ability of rpm to verify contents (the -V
option). I wasn't planning on explicitly dis-allowing it, but I'm not
going to recommend it.
> Actually we may not be that far apart. Maybe
some of our cases do not conflict.
I'm glad to hear you say that :)
> > 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?
Sure I want to run all phases but in this way.
- During the collect and install phase we are preparing the image to be
used by the user. As you say copying and doing things that can't be
broken easily. In the case of shared install this requires admin authority.
Okay.
- During the configure phase we are customizing the setup for the
specific user and his specific workspace
This is where we differ. We're not doing any per-user or per-workspace
customization. That is all done by the user.
For your case we are just
storing the user(admin) data in the shared tree so that it can be used
by all users.
To what data are you referring here?
- In the case of a native bundle that has to have a libpath set in the
environment, how would you handle? How would you handle an upgrade?
Well, my knee-jerk reaction is "environment variables are evil and
should be avoided at all costs" :) If the runtime couldn't find things
in sane places by default, I guess I'd make some sort of wrapper script
or something that set variables.
A more complicated case is the JVM.
In our case we just Require (at the RPM level) a JVM and the rest is
taken care of automatically.
Each JVM has a set of properties that
it should be launched with. In addition to these, there are properties
that each user or more likely a product configurator might add.
Can these product properties go in a per-product file somewhere?
> > 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.
Some products ship with a JVM. In the case of XPD product, we ship with
jclDesktop but provide an update site so they can change to J2SE. So in
this case the jclDesktop would be in the shared space. How would you
reconcile jclDesktop in shared bundles.txt and J2SE in user bundles.txt?
Or how would you accommodate jclDesktop and J2SE in the shared space?
This is a situation I was explicitly designing against. Having users
override shared behaviour significantly reduces the benefits of having a
shared installation and makes manageability a nightmare.
> 1) user home directories shouldn't (and sometimes can't) be touched by
> an RPM installation
I agree. And conversely the user process should not modify the shared.
Of course. They won't be able to in our case due to permissions.
Creating a bundles.txt from root IUs is provisioning in its simplest
form. Aren't root IUs described in the profile?
Yeah, but I'm proposing not having a profile.
Andrew
