[
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 <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
original statement).
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).
Andrew
