Re: [dev] Where our products install to

[Stephan Bergmann]

Minor update (no pun intended):  The minor (".0") is dropped from the 
OpenOffice.org brand layer (see 
).  This means 
that cross-minor updates for OOo can potentially be smaller.


Stephan Bergmann wrote:

Hi all,

With the advent of the newly structured three layer OOo 3 (see 
), 
the question arises into what directory structure the various parts of 
the products shall be installed.


The old (OOo 2.4) structures were as follows:

On Unix (Linux, Solaris):
- The URE product by default installed to /opt/openoffice.org/ure (where 
the complete /opt/openoffice.org/ure prefix was relocatable).
- The OOo product by default installed to /opt/openoffice.org2.4 (where 
the complete /opt/openoffice.org2.4 prefix was relocatable).
- The StarOffice product, for example, by default installed to 
/opt/staroffice8 (where the complete /opt/staroffice8 prefix was 
relocatable).


On Windows:
- The URE product by default installed to \URE (where the 
complete \Ure prefix was relocatable).
- The OOo product by default installed to \OpenOffice.org 
2.4 (where the complete \OpenOffice.org 2.4 prefix was 
relocatable).
- The StarOffice product, for example, by default installed to Files>\Sun\StarOffice 8 (where the complete Files>\Sun\StarOffice 8 prefix was relocatable).


The planned new (OOo 3.0) structures are as follows:

On Unix (Linux, Solaris):
- The URE product still by default will install to 
/opt/openoffice.org/ure (but only the /opt prefix is relocatable).

- The OOo product by default will install its three layers into
-- /opt/openoffice.org/ure
-- /opt/openoffice.org/basis3.0
-- /opt/openoffice.org3.0
 (where only the /opt prefix is relocatable).
- The StarOffice product, for example, by default will install its three 
layers into

-- /opt/openoffice.org/ure
-- /opt/openoffice.org/basis3.0
-- /opt/staroffice9
 (where only the /opt prefix is relocatable).

On Windows:
- The URE product by default will install to Files>\OpenOffice.org\URE (where only the  prefix is 
relocatable).

- The OOo product by default will install its three layers into
-- \OpenOffice.org\URE
-- \OpenOffice.org\Basis 3.0
-- \OpenOffice.org 3.0
 (where only the  prefix is relocatable).
- The StarOffice product, for example, by default will install its three 
layers into

-- \OpenOffice.org\URE
-- \OpenOffice.org\Basis 3.0
-- \Sun\StarOffice 9
 (where only the  prefix is relocatable).

Where (on both Unix and Windows) the ure layer is shared across any 
installed URE, OOo, StarOffice, etc. products, and the brand layer is 
shared across any installed OOo, StarOffice, etc. products:  If 
installation finds a layer already installed somewhere on the machine 
(probably relocated), it re-uses that installed layer.


On Mac OS X, we will continue with self-contained installation sets for 
now, i.e., an OOo and a StarOffice will each contain (identical copies 
of) ure and basis layers, which they do not share.  This may change 
later on.


The rationale for the new structures is as follows:

- When a user requests to relocate an installation to some prefix X, the 
user expects that everything is installed under X (according to AK). 
Thus, the common relocatable prefix of the three layers can not be 
longer than the longest common prefix of all the filepaths installed 
into the layers (i.e., only /opt resp. ).  Since URE and 
OOo, StarOffice, etc. share the ure layer, the relocatable prefix of the 
URE also had to be shortened (on Unix).


- The user-relevant paths have not changed.  URE (on Unix) is still 
found at /opt/openoffice.org/ure, OOo is still found at 
/opt/openoffice.orgX.Y resp. \OpenOffice.org X.Y, and for 
example StarOffice is still found at /opt/starofficeX resp. Files>\Sun\StarOffice X.


- If an installation finds an older ure (or basis) layer than it needs, 
it should be possible to allow for updating the existing layer.  On 
Windows, according to IS, this would not be possible for the existing 
URE product, however.  So, we decided to ignore any existing pre-OOo3 
URE installations on Windows (of which there are probably only very few, 
anyway) and use a new path for the new, OOo3-and-beyond URE.


Input, anyone?

-Stephan


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[dev] Dictionaries for spell checking etc... (was: Re: [dev] Where our products install to)

[Thomas Lange - Sun Germany - ham02 - Hamburg]

Hi all,

@Caolan, Petr:
I have made this answer of mine a cross post to lingucopmponent.dev as
well. And since it is about lingucomponent issues it would be nice to
continue the discussion there

@lingucomoment reades:
This mail is a reply to a posting in the openoffice.dev list.



> On Fri, 2008-02-08 at 14:05 +0100, Petr Mladek wrote:
>>
>> I think that the best solution would be to get rid of share/dict/ooo and 
>> look 
>> for the dictionaries into a common place, for example /usr/share/myspell.
>> 
>> It would be nice get rid of share/dict/ooo/dictionary.lst. The dictionaries 
>> have well defined names. It is possible to create symlinks for compatible 
>> languages, ... Well, there might be problems with symlinks on Windows but it 
>> would be very useful on Linux.
> 
> Specifically wrt dictionaries, as you probably know that's precisely
> what we do on fedora where we've done away with dictionary.lst (well it
> still works if you want to use it) and just auto-detect them and the
> language/locale they service based on their names and add looking in a
> system /usr/share/myspell location as well the shared OOo one and then
> the per-user one.
> 
> 
> If there's any interest in it, then I could try and perhaps upstream
> this work and co-opt the existing --without-myspell-dicts or whatever
> its called into a sort of --with-system-dicts=LOCATION and bind the code
> off that, or something of that nature.

It seems you guys have your own way with fedora to get rid of the
dictionary.lst.

Since we currently are in the same process I'd like to describe shortly
what we are doing. From what I understood here so far our concept is
different but both should be able to be used concurrently.
Well at least if we sort out some issues of precedence if dictionaries
for the same language and purpose are installed at various places and be
identified with various means.

Our planned, and for the most part by now implemented, idea was to allow
for dictionaries to be installed/distributed as extensions. Thus our
approach needs several new configuration entries.
BTW as with OOo 3.0 we want to get red of the way those things currently
work in OOo.
In the meantime when my CWS tl41 is finished an is integrated the old
and new behaviour will work both for a while. And for OOo 3.0 a proper
migration from the old-working-way to the new one using configuration
entries is planned. After that the old code should be removed.


Now on to what we currently do or did in the CWS
- the path settings for 'Linguistic' and 'Dictionary' have been
  changed to be multi-paths.
  The new 'Dictionary' path is now dedicated to those personal
  user-dictionaries as it always should have been.
  And the 'Linguistic' path is for data etc. that is to be used
  and found by an actual spell checker, hyphenator, ... implementation

Thus those cnfiguration setting will soon look like this:







$(userurl)/wordbook








$(userurl)/wordbook




As you can see the 'Linguistic' path covers all places where previously
data files for the linguistic might have been installed.
The 'UserPaths' entry is actually a string list and thus can also hold
more than one path.


The next we did is:
- spell checkers, hyphenators, ... need to make configuration entries
  that describe what type of dictionary the may make use of.

Such an enty will look like this:




DICT_SPELL MySpell_old





The component has to specifiy it's implementation name and a list of
dictionary formats it may make use of.
We don't have implementations that make use of more than one format at
the same time yet but we want to be flexible and future-safe with our
new configuration entries.
For example in the future we could have a dictionary format named
DICT_SPELL_EXCEPT
that is used to identify exception dictionaries. Something that Hunspell
currently does not implement, but hopefully will do so at some point.
Then it would be normal to support the two formats
DICT_SPELL and DICT_SPELL_EXCEPT
at the same time.


On the other side of the line we now have the new entries for dictionaries:
- dictionaries need to make entries in the configuration that
  state what they are to be used for.

I may look like this:




%origin%/dictionaries/de_CH.aff
%origin%/dictionaries/de_CH.dic


DICT_SPELL


de-CH




%origin%/dictionaries/en_US.aff
%origin%/dictionaries/en_US.dic


DICT_SPELL


en-US





Especially this will easily allow to use the 

Re: [dev] Where our products install to

[Rene Engelhard]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

Stephan Bergmann wrote:
> Rene Engelhard wrote:
>> So you want to tellme that /usr/lib/openoffice won't work anymore
>> (be it with /usr/lib/openoffice/ure, /usr/lib/openoffice/basic3.0)
>> anymore?
>
> Using /usr/lib instead of /opt as prefix should just work fine, I guess.  
>  (In principle, the three layers can be put wherever you want; all that  
> needs to be adjusted are two symbolic links: the brand layer has a  
> symbolic link "basis-link" to the basis layer, and the basis layer has a  
> symbolic link "ure-link" to the ure layer.  Especially folks that  

Aha, that's good to know. Because I do want to keep the installdir
version-number free. That of course wouldn't have worked if it expected
openoffice.org3.0 somewhere. If it's just done via links, that's fine
for me, too.

Thanks for the clarification.

> package OOo into some specific distro format should find no real  
> problems with the new structure, I hope.  But if there are any details  

Yeah, I hope so, too.

> with the structure that could be improved from your point of view, do  
> tell now, as long as the structure is still soft and can be modified  
> rather easily.)

I currently don't see one, but then again I didn't yet invest any work
in packaging 3.0 snapshots...

Regards,

Rene
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHsBM4+FmQsCSK63MRAlv8AJ9ry+gpoovrKOV00B+z+HeIpBfoiACfdD6T
qwThxK7JO0df/qKo/7VTeck=
=3PE+
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [dev] Where our products install to

[Stephan Bergmann]

Rene Engelhard wrote:

So you want to tellme that /usr/lib/openoffice won't work anymore
(be it with /usr/lib/openoffice/ure, /usr/lib/openoffice/basic3.0)
anymore?


Using /usr/lib instead of /opt as prefix should just work fine, I guess. 
 (In principle, the three layers can be put wherever you want; all that 
needs to be adjusted are two symbolic links: the brand layer has a 
symbolic link "basis-link" to the basis layer, and the basis layer has a 
symbolic link "ure-link" to the ure layer.  Especially folks that 
package OOo into some specific distro format should find no real 
problems with the new structure, I hope.  But if there are any details 
with the structure that could be improved from your point of view, do 
tell now, as long as the structure is still soft and can be modified 
rather easily.)


-Stephan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [dev] Where our products install to

[Stephan Bergmann]

Oliver Braun wrote:

Stephan Bergmann wrote:

The planned new (OOo 3.0) structures are as follows:

On Unix (Linux, Solaris):
- The URE product still by default will install to 
/opt/openoffice.org/ure (but only the /opt prefix is relocatable).

- The OOo product by default will install its three layers into
-- /opt/openoffice.org/ure
-- /opt/openoffice.org/basis3.0
-- /opt/openoffice.org3.0
 (where only the /opt prefix is relocatable).
- The StarOffice product, for example, by default will install its 
three layers into

-- /opt/openoffice.org/ure
-- /opt/openoffice.org/basis3.0
-- /opt/staroffice9
 (where only the /opt prefix is relocatable).


In light of recent events: how will the new directory structure affect 
LD_LIBRARY_PATH set in the soffice launch script ?


It would be nice to have only a small subset of libraries in the 
directories added to LD_LIBRARY_PATH, especially none of the external. 
Maybe we create an extra directory (for the purpose of minimizing the 
number of libs present) and populate it with symbolic links to the real 
libs ?!


I did a lot of work on CWS sb83 to clean up finding of all sorts of 
dependent libraries (URE libraries, OOo libraries, external libraries, 
extensions, ...), on all the various platforms; see the new 
(APP|SHL)nRPATH stuff.


desktop/scripts/soffice.sh:1.28.34.8 etc. still contain code to mess 
around with LD_LIBRARY_PATH etc. and PATH (simply because I did not yet 
touch that code), but it (a) is probably not needed any longer, and (b) 
probably sets wrong, useless paths (brand vs. basis) anyway---and OOo 
continues to work for me, at least in "standard" situations.


Let me know of any LD_LIBRARY_PATH related problems, and we can see 
whether they are already solved on sb83, or do solve them.


-Stephan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [dev] Where our products install to

[Stephan Bergmann]

Oliver Braun wrote:

Hi Stephan,

Stephan Bergmann wrote:

The planned new (OOo 3.0) structures are as follows:

On Unix (Linux, Solaris):
- The URE product still by default will install to 
/opt/openoffice.org/ure (but only the /opt prefix is relocatable).

- The OOo product by default will install its three layers into
-- /opt/openoffice.org/ure
-- /opt/openoffice.org/basis3.0
-- /opt/openoffice.org3.0
 (where only the /opt prefix is relocatable).
- The StarOffice product, for example, by default will install its 
three layers into

-- /opt/openoffice.org/ure
-- /opt/openoffice.org/basis3.0
-- /opt/staroffice9
 (where only the /opt prefix is relocatable).


Is there a good reason to keep the minor (3.0) in the path names and 
thus to continue to lose (super-)user deployed dictionaries and UNO 
extensions when upgrading from e.g. 3.0 to 3.1 ?


- The versioning of the basis directory (3 vs. 3.0 vs. 3.0.0) is 
constrained by the compatibility characteristics of the interface 
between basis and brand layer:  If we can keep that interface compatible 
among minors, we can label the basis directory just "3"; if we can only 
keep that interface compatible among micors, we need to label it "3.0"; 
if, however, we would not even manage that, we would need to label it 
"3.0.0".  As it stands now, the interface will be rather thin, the brand 
layer only containing startup code for the executables (and the meat of 
the executables residing in the basis layer, with few simple entry 
points), some .ini/rc files, bitmaps, icons, configuration entries, 
extensions (which should only be programmed against the URE, anyway), 
etc.  But---compatibility is a hard problem, so I am not sure we will 
manage to stay compatible between minors.


- For dictionaries, see the parallel sub-thread by Petr and Caolan.

- Shared extensions for now will always go into the brand layer, anyway. 
 (Rationale: there are brands that bring with them brand-specific 
extensions.)  Note that this could be changed in the future, by having 
three extension layers instead of the current two.


-Stephan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [dev] Where our products install to

[Stephan Bergmann]

Caolan McNamara wrote:

On Fri, 2008-02-08 at 14:05 +0100, Petr Mladek wrote:
I think that the best solution would be to get rid of share/dict/ooo and look 
for the dictionaries into a common place, for example /usr/share/myspell.


It would be nice get rid of share/dict/ooo/dictionary.lst. The dictionaries 
have well defined names. It is possible to create symlinks for compatible 
languages, ... Well, there might be problems with symlinks on Windows but it 
would be very useful on Linux.


Specifically wrt dictionaries, as you probably know that's precisely
what we do on fedora where we've done away with dictionary.lst (well it
still works if you want to use it) and just auto-detect them and the
language/locale they service based on their names and add looking in a
system /usr/share/myspell location as well the shared OOo one and then
the per-user one.


If there's any interest in it, then I could try and perhaps upstream
this work and co-opt the existing --without-myspell-dicts or whatever
its called into a sort of --with-system-dicts=LOCATION and bind the code
off that, or something of that nature.


I guess Thomas Lange can add to this thread.  (I mainly worked on 
keeping the old code up and running in the new structures largely 
unchanged, but any additional improvements are of course welcome.)


-Stephan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [dev] Where our products install to

[Stephan Bergmann]

Caolan McNamara wrote:

I'm still kind of interesting in figuring out if splitting the build to
make building ure on its own and then building the rest of OOo against
an intalled ure is plausible or desirable. Quite messy to do it now, but
hackable. That's the grail for the "we always build packages from
scratch each time" distros.


That's work largely orthogonal to what we (Ingo Schmidt and I) are 
doing.  Petr Mladek wanted to invest energy into this.


-Stephan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [dev] Where our products install to

[Rene Engelhard]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Stephan Bergmann wrote:
> The planned new (OOo 3.0) structures are as follows:
>
> On Unix (Linux, Solaris):
> - The URE product still by default will install to  
> /opt/openoffice.org/ure (but only the /opt prefix is relocatable).
> - The OOo product by default will install its three layers into
> -- /opt/openoffice.org/ure
> -- /opt/openoffice.org/basis3.0
> -- /opt/openoffice.org3.0
>  (where only the /opt prefix is relocatable).
> - The StarOffice product, for example, by default will install its three  
> layers into
> -- /opt/openoffice.org/ure
> -- /opt/openoffice.org/basis3.0
> -- /opt/staroffice9
>  (where only the /opt prefix is relocatable).
[...]
> Input, anyone?

So you want to tellme that /usr/lib/openoffice won't work anymore
(be it with /usr/lib/openoffice/ure, /usr/lib/openoffice/basic3.0)
anymore?

That's bad, /opt is in the FHS reserved for *third-party*
addon-packages, distributions must not install there (many do, though,
but...), the right path is /usr/lib/.

Will the new structure support that? (In emergency
/usr/lib/openoffice.org3.0 or so would be ok, too, but I really want to
avoid having the version in the installdir name).

Regards,

Rene
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHrZKu+FmQsCSK63MRAsx2AJ0V3w6cpnfBrHJDK0j/u3dPtsQcAwCfcNc+
Qhq2tmJGcelcicnwhCI0vfw=
=Htj6
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [dev] Where our products install to

[Oliver Braun]

Stephan Bergmann wrote:

The planned new (OOo 3.0) structures are as follows:

On Unix (Linux, Solaris):
- The URE product still by default will install to 
/opt/openoffice.org/ure (but only the /opt prefix is relocatable).

- The OOo product by default will install its three layers into
-- /opt/openoffice.org/ure
-- /opt/openoffice.org/basis3.0
-- /opt/openoffice.org3.0
 (where only the /opt prefix is relocatable).
- The StarOffice product, for example, by default will install its three 
layers into

-- /opt/openoffice.org/ure
-- /opt/openoffice.org/basis3.0
-- /opt/staroffice9
 (where only the /opt prefix is relocatable).


In light of recent events: how will the new directory structure affect 
LD_LIBRARY_PATH set in the soffice launch script ?


It would be nice to have only a small subset of libraries in the directories 
added to LD_LIBRARY_PATH, especially none of the external. Maybe we create an 
extra directory (for the purpose of minimizing the number of libs present) and 
populate it with symbolic links to the real libs ?!


Oliver

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [dev] Where our products install to

[Caolan McNamara]

On Fri, 2008-02-08 at 14:05 +0100, Petr Mladek wrote:
>
> I think that the best solution would be to get rid of share/dict/ooo and look 
> for the dictionaries into a common place, for example /usr/share/myspell.
> 
> It would be nice get rid of share/dict/ooo/dictionary.lst. The dictionaries 
> have well defined names. It is possible to create symlinks for compatible 
> languages, ... Well, there might be problems with symlinks on Windows but it 
> would be very useful on Linux.

Specifically wrt dictionaries, as you probably know that's precisely
what we do on fedora where we've done away with dictionary.lst (well it
still works if you want to use it) and just auto-detect them and the
language/locale they service based on their names and add looking in a
system /usr/share/myspell location as well the shared OOo one and then
the per-user one.


If there's any interest in it, then I could try and perhaps upstream
this work and co-opt the existing --without-myspell-dicts or whatever
its called into a sort of --with-system-dicts=LOCATION and bind the code
off that, or something of that nature.


C.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [dev] Where our products install to

[Petr Mladek]

On Friday 08 February 2008, Oliver Braun wrote:
> Hi Stephan,
>
> Stephan Bergmann wrote:
> > The planned new (OOo 3.0) structures are as follows:
> >
> > On Unix (Linux, Solaris):
> > - The URE product still by default will install to
> > /opt/openoffice.org/ure (but only the /opt prefix is relocatable).
> > - The OOo product by default will install its three layers into
> > -- /opt/openoffice.org/ure
> > -- /opt/openoffice.org/basis3.0
> > -- /opt/openoffice.org3.0
> >  (where only the /opt prefix is relocatable).
> > - The StarOffice product, for example, by default will install its three
> > layers into
> > -- /opt/openoffice.org/ure
> > -- /opt/openoffice.org/basis3.0
> > -- /opt/staroffice9
> >  (where only the /opt prefix is relocatable).
>
> Is there a good reason to keep the minor (3.0) in the path names and thus
> to continue to lose (super-)user deployed dictionaries and UNO extensions
> when upgrading from e.g. 3.0 to 3.1 ?

I think that the best solution would be to get rid of share/dict/ooo and look 
for the dictionaries into a common place, for example /usr/share/myspell.

It would be nice get rid of share/dict/ooo/dictionary.lst. The dictionaries 
have well defined names. It is possible to create symlinks for compatible 
languages, ... Well, there might be problems with symlinks on Windows but it 
would be very useful on Linux.


-- 
Best Regards,

Petr Mladek
software developer
-  
SUSE LINUX, s. r. o.e-mail: [EMAIL PROTECTED]
Lihovarská 1060/12  tel: +420 284 028 952
190 00 Prague 9 fax: +420 284 028 951
Czech Republic  http://www.suse.cz/

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [dev] Where our products install to

[Oliver Braun]

Hi Stephan,

Stephan Bergmann wrote:

The planned new (OOo 3.0) structures are as follows:

On Unix (Linux, Solaris):
- The URE product still by default will install to 
/opt/openoffice.org/ure (but only the /opt prefix is relocatable).

- The OOo product by default will install its three layers into
-- /opt/openoffice.org/ure
-- /opt/openoffice.org/basis3.0
-- /opt/openoffice.org3.0
 (where only the /opt prefix is relocatable).
- The StarOffice product, for example, by default will install its three 
layers into

-- /opt/openoffice.org/ure
-- /opt/openoffice.org/basis3.0
-- /opt/staroffice9
 (where only the /opt prefix is relocatable).


Is there a good reason to keep the minor (3.0) in the path names and thus to 
continue to lose (super-)user deployed dictionaries and UNO extensions when 
upgrading from e.g. 3.0 to 3.1 ?


Regards,
Oliver

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [dev] Where our products install to

[Caolan McNamara]

On Fri, 2008-02-08 at 12:23 +0100, Stephan Bergmann wrote:
> Input, anyone?

All seems very reasonable, firefox and other similar xul using apps
sitting up on top of a common xulrunner comes to mind as a precedent.

I'm still kind of interesting in figuring out if splitting the build to
make building ure on its own and then building the rest of OOo against
an intalled ure is plausible or desirable. Quite messy to do it now, but
hackable. That's the grail for the "we always build packages from
scratch each time" distros.

C.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[dev] Where our products install to

[Stephan Bergmann]

Hi all,

With the advent of the newly structured three layer OOo 3 (see 
), 
the question arises into what directory structure the various parts of 
the products shall be installed.


The old (OOo 2.4) structures were as follows:

On Unix (Linux, Solaris):
- The URE product by default installed to /opt/openoffice.org/ure (where 
the complete /opt/openoffice.org/ure prefix was relocatable).
- The OOo product by default installed to /opt/openoffice.org2.4 (where 
the complete /opt/openoffice.org2.4 prefix was relocatable).
- The StarOffice product, for example, by default installed to 
/opt/staroffice8 (where the complete /opt/staroffice8 prefix was 
relocatable).


On Windows:
- The URE product by default installed to \URE (where the 
complete \Ure prefix was relocatable).
- The OOo product by default installed to \OpenOffice.org 
2.4 (where the complete \OpenOffice.org 2.4 prefix was 
relocatable).
- The StarOffice product, for example, by default installed to Files>\Sun\StarOffice 8 (where the complete Files>\Sun\StarOffice 8 prefix was relocatable).


The planned new (OOo 3.0) structures are as follows:

On Unix (Linux, Solaris):
- The URE product still by default will install to 
/opt/openoffice.org/ure (but only the /opt prefix is relocatable).

- The OOo product by default will install its three layers into
-- /opt/openoffice.org/ure
-- /opt/openoffice.org/basis3.0
-- /opt/openoffice.org3.0
 (where only the /opt prefix is relocatable).
- The StarOffice product, for example, by default will install its three 
layers into

-- /opt/openoffice.org/ure
-- /opt/openoffice.org/basis3.0
-- /opt/staroffice9
 (where only the /opt prefix is relocatable).

On Windows:
- The URE product by default will install to Files>\OpenOffice.org\URE (where only the  prefix is 
relocatable).

- The OOo product by default will install its three layers into
-- \OpenOffice.org\URE
-- \OpenOffice.org\Basis 3.0
-- \OpenOffice.org 3.0
 (where only the  prefix is relocatable).
- The StarOffice product, for example, by default will install its three 
layers into

-- \OpenOffice.org\URE
-- \OpenOffice.org\Basis 3.0
-- \Sun\StarOffice 9
 (where only the  prefix is relocatable).

Where (on both Unix and Windows) the ure layer is shared across any 
installed URE, OOo, StarOffice, etc. products, and the brand layer is 
shared across any installed OOo, StarOffice, etc. products:  If 
installation finds a layer already installed somewhere on the machine 
(probably relocated), it re-uses that installed layer.


On Mac OS X, we will continue with self-contained installation sets for 
now, i.e., an OOo and a StarOffice will each contain (identical copies 
of) ure and basis layers, which they do not share.  This may change 
later on.


The rationale for the new structures is as follows:

- When a user requests to relocate an installation to some prefix X, the 
user expects that everything is installed under X (according to AK). 
Thus, the common relocatable prefix of the three layers can not be 
longer than the longest common prefix of all the filepaths installed 
into the layers (i.e., only /opt resp. ).  Since URE and 
OOo, StarOffice, etc. share the ure layer, the relocatable prefix of the 
URE also had to be shortened (on Unix).


- The user-relevant paths have not changed.  URE (on Unix) is still 
found at /opt/openoffice.org/ure, OOo is still found at 
/opt/openoffice.orgX.Y resp. \OpenOffice.org X.Y, and for 
example StarOffice is still found at /opt/starofficeX resp. Files>\Sun\StarOffice X.


- If an installation finds an older ure (or basis) layer than it needs, 
it should be possible to allow for updating the existing layer.  On 
Windows, according to IS, this would not be possible for the existing 
URE product, however.  So, we decided to ignore any existing pre-OOo3 
URE installations on Windows (of which there are probably only very few, 
anyway) and use a new path for the new, OOo3-and-beyond URE.


Input, anyone?

-Stephan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]