[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [equinox-dev] [prov] Comments on wiki "Equinox p2 Shared Install Plan"
- From: Andrew Overholt <overholt@xxxxxxxxxx>
- Date: Fri, 21 Dec 2007 09:59:06 -0500
- Delivered-to: firstname.lastname@example.org
- User-agent: Thunderbird 220.127.116.11 (X11/20071115)
* James D Miles <jdmiles@xxxxxxxxxx> [2007-12-20 13:05]:
> > > > >> 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."
I have no problem with sane defaults. However, the true default should be
buried in eclipse somewhere.
Yeah, in the launcher sequence of the product, right?
To provide a sane default that varies depending on the user would seem
to mean that you would somehow have to wrapper eclipse native. We have
gone through several iterations of controlling this.
I hope we don't have anything that depends upon the user. It should
just be <user.home>/.<productid> (or some such sane default), right?
However there is a config phase to be run even for RPM install. It is
just deferred until the user starts the platform. Yes, RPM is not
involved in that.
Yes, I understand. I hope to get to the point where I re-write the
FileInitializer we wrote back in the day as a touchpoint operation.
That was originally done to allow us to extract shared libraries from
jars which bundle them -- ie. SWT -- and put them in a system-wide place
(the original impetus was that some systems have /home mounted noexec).
> > 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?
I am referring to all of the data that is normally written during the
execution of eclipse. In eclipse prior to p2 the modifiable data could
be found in the workspace directory (-data location_arg) or the
configuration directory (-configuration location_arg). Anything else
in the install tree could be assumed to be nonmodifiable (updates
excluded). Under that model, we would find the bundles.txt in the
configuration directory. In p2 I believe they are separating p2 bundle
data out from the configuration area but it could be rolled back in
using the eclipse.p2.data.area property. Being able to locate
everything on a relative basis has been extremely important.
Ah, I see what you mean and I agree with your points (including the
Have you thought about allowing mounts to your shared install?
What do you mean by that? Do you mean allowing machines to share, say,
/usr/share/eclipse? If so, I am planning on that Just Working.
> > 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.
I don't see what difference this makes since you are not supporting
upgrades except through RPM. If you are allowing the admin to
customize (even though it is not recommended) then a profile should be
included. I could be wrong here, I don't have a good enough
understanding of our profiles and root IUs yet.
That was what I meant before when I said I was going to try to
materialize a profile from the metadata (and loaded bundles ... not sure
about that yet).