Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[equinox-dev] [prov] Shared install filesystem layout


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
/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 \

# Error:  The Eclipse executable launcher was unable to locate its
# companion launcher jar


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.



Attachment: pgpPoApAV9DP9.pgp
Description: PGP signature

Back to the top