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

> > - how do you generally handle versions?  for example, it is imaginable
> > that people need Eclipse 3.3 and 3.4 installed.  They both have
> > eclipse.exe, eclipse.ini, ...  Are they packaged with unique names?
>
> Well, in Fedora it's easy because we only ship one version :)  But I
> imagine you'd solve this with a prefix or something:
> ex. /usr/lib/eclipse34 or even (but please no) /opt/eclipse34.

On some systems (e.g. Debian) the use of /etc/alternatives is quite
common. The code is put in a per-directory with version, and then
there's a symbolic link for the system-wide 'default' one:

/etc/alternatives/eclipse -> /usr/lib/eclipse_3-3/eclipse

Others can then use different versions by changing their path.

BTW the /usr/share/ stuff is listed at:

http://www.pathname.com/fhs/pub/fhs-2.3.html#USRSHAREARCHITECTUREINDEPENDENTDATA

"The /usr/share hierarchy is for all read-only architecture
independent data files. [30]

This hierarchy is intended to be shareable among all architecture
platforms of a given OS; thus, for example, a site with i386, Alpha,
and PPC platforms might maintain a single /usr/share directory that is
centrally-mounted. Note, however, that /usr/share is generally not
intended to be shared by different OSes or by different releases of
the same OS."

There was some talk a while ago of creating a /usr/share/java for such
things. Given that the .jars are architecture independent (even if
some of their contents aren't) I'd vote for not splitting the bundles
arbitrarily.

Alex.