[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [equinox-dev] [prov] Shared install filesystem layout
|
- When you use the name "eclipse" in paths, does it refer to the "eclipse"
product (aka Fedora Eclipse), or to eclipse the ecosystem? In other words,
if I was installing some other eclipse based application where would the
plug-ins go, in a folder called "eclipse" or in a folder called
"myApplication" ? Or another way again, is the folder
/usr/share/eclipse/plugins the shared pool of plugin for all the eclipse
based applications on the system?
- With the separation of platform independent and platform specific code,
how do you deal with SWT fragments? Do you explode it and spread its
content into various folders?
- Rumors came to my hear that you were sharing jars such as tomcat and
others, how does that fit in this layout?
- Where would plug-ins downloaded by a specific user go? (Feel free to
delay the answer to this :-))
PaScaL
Andrew Overholt
<overholt@redhat.
com> To
Sent by: equinox-dev@xxxxxxxxxxx
equinox-dev-bounc cc
es@xxxxxxxxxxx
Subject
[equinox-dev] [prov] Shared install
08/10/2007 11:41 filesystem layout
AM
Please respond to
Andrew Overholt
<overholt@redhat.
com>; Please
respond to
Equinox
development
mailing list
<equinox-dev@ecli
pse.org>
Hi,
After discussing shared installs with Pascal a bit more, we decided that
it would be best for me to come up with an ideal file system layout and
work backwards from there. So in an ideal, FHS-compliant [1] world
(this is just my interpretation of the FHS but it'll suffice for
arguments sake) we'd have:
/usr/bin/eclipse - actual launcher binary (preferably not a wrapper)
/usr/share/eclipse/plugins - platform-independent plugins
/usr/share/eclipse - rest of platform-independent stuff
/usr/lib/eclipse/plugins - platform-dependent plugins (fragments)
/usr/lib64/eclipse/plugins - platform-dependent plugins for bi-arch
systems (ex. if both x86 and x86_64 version
of Eclipse are installed on the
same x86_64
system)
/etc/eclipse - machine-specific (system-wide) Eclipse configuration
information
/var/lib/eclipse - variable state information for running Eclipse
/var/cache/eclipse - cached Eclipse application information
/var/lock/eclipse - lock file(s)
/var/log/eclipse - log file(s)
--------------
/home/<user>/.eclipse - user-specific configuration, preferences, profile,
etc.
A few questions that remain:
- Do we really need to separate things in /var like that?
-- Probably not, but it'd be nice if we could.
- Where would a system-wide profile go? /var/lib/eclipse? The FHS
states that /usr should be read-only except at
installation/un-installation time so a literal interpretation may
preclude putting the profile there.
I realize that some of this is already achievable with 3.3 or 3.4
I-builds of the SDK. For fun, I tried the following:
<grab I20070809-1105>
mkdir slash; cd slash
mkdir -p usr/{bin,lib,share}
cd usr/share
tar zxf ~/eclipse-SDK-I20070809-1105-linux-gtk.tar.gz
cd eclipse
# Let's try moving the binary:
mv eclipse ../../bin
pushd ../../bin
./eclipse --launcher.library \
../share/eclipse/plugins/org.eclipse.equinox.launcher.gtk.linux.x86_1.0.100.v20070730/eclipse_1101.so
# Error: The Eclipse executable launcher was unable to locate its
# companion launcher jar
popd
Perhaps I'm just not using --launcher.library correctly. We (Fedora
Eclipse) currently carry a patch to the launcher to make it find the
sharedConfiguration area in /usr/lib{,64}/eclipse/configuration and to
make it see that the rest of the install is in /usr/share/eclipse. But
it's a lame patch that just hard-codes the values.
So assuming we can find a solution to the separate binary launcher
issue, let's look at the idea of putting fragments into
/usr/lib{,64}/eclipse/plugins while keeping the rest of the plugins in
/usr/share/eclipse. We currently use a links file to do this. Can we
expect to support this with the provisioning work? What about setting
up such a split install at instance provisioning time?
I realize some of these may be trivial concerns, but if we can hammer
these out, we can work towards the shared/hierarchical/composite
profiles I brought up earlier.
Andrew
[1]
http://www.pathname.com/fhs/
(See attached file: attg0qzb.dat)
_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev
Attachment:
attg0qzb.dat
Description: Binary data