I've seen such a feature while installing Paint Shop and I think it's a good idea.

Yes, we can think about this with the introduction of a new update process for
OOo 3.0. Currently we use on Windows the mayor upgrade, which means
uninstallation of the old product and following installation of the new product.

Sometimes a step back can be a step forward.

In OOo1.x we had sversion.ini that created an indirection for the location of
the current profile of a user. Mozilla originated applications have something
comparable called profiles.ini.

Perhaps we should think about that also. The profile.ini wouldn't be removed on
upgrade.

A profile.ini should be provided in the "presets" folder and will be copied to
the $SYSUSERCONFIG folder if there is none. So an admin can prepare it in a way
that all users get the same profile.ini (if wanted), but an upgrade will not
overwrite it in case there is one from a prior installation.

What do you think about that?

Sounds good. The soffice has to check the existence of profile.ini in
$SYSUSERCONFIG and copy this file if necessary. After the file is copied, a
change of profile.ini in "presets" folder will not affect the locally copied
profile.ini. It seems, as if we can do it in this way.

Of course this would mean to change the bootstrap variables evaluation as
bootstrap.ini again needs to support something like what we had in OOo1.x and
the bootstrap vars access must be able to cope with an ini file. So we need to
commitment of others too.

Kay, what do you think?

Adapting the bootstraprc (.ini) to resolve the "UserInstallation" variable by
looking into a file (.sversionrc) in the users home is a matter of seconds. I
suggest to remove the variable entirely from the boostraprc and to adapt the
configmgrrc accordingly.

If we actually want to enable the use of multiple profiles by end users, we
likely need to provide "a profile selection and management" dialog, e.g. as
Firefox has.

What would be the end users benefit from having multiple user layers? I'm not
sure whether this is worth the effort of implementation (and QA at last). And
what else should be controlled when updating a previous version? Which xcu files
have to be handled?

The benefit for users is that the place of their profile survives an update.
This is the root cause of this RFE.

OOo already can have more than one profile per user so that isn't a new feature.
What would be new is that you don't need to create special command lines to
access the different profiles but can do it by using a new profile selection
dialog. This can be a standalone tool BTW.

And as a frequent user of Firefox/Thunderbird and also a frequent user of
multiple OOo installations on one machine: yes, an easy way to configure the
place of my profile *is* beneficial and useful and justifies some effort.

And the effort isn't large BTW.

I see problems to define a place for such a file. On Windows you can have for
example: All user data in "Dokumente und Einstellungen" (German) with write
access for the user or you can have a home-directory on the server and server
based profiles including "Dokumente und Einstellungen" which are mandatory and
changes would not be persistent there.

A GUI tool to create multiple user profiles has nothing to do with the
'survival' of an existing user profile. BTW: The profile always survives. The
normal user needs one user profile in $SYSUSERCONFIG. For testers, power user
and developer we have the well known way to edit the bootstrap file. So I would
assume that it is a use case to have GUI to define where the user profile should
be placed but not to have multiple profiles in such a tool. As we always wanted
to keep it simple.

I don't need a GUI tool at all for this. A profile.ini where I can hack
different locations would be enough. It was Kay who asked for a GUI tool. 

@Regina: I don't understand your problem. Nowadays we automatically put the
profile somewhere, e.g. in "application data" on Windows or the home folder on
Linux. My proposal is to put the profile.ini file there also. And the user
profile by default still should go into that folder, profile.ini will point to it.

But if I wanted to use a different folder I could change it easily by editing
the profile.ini file. Not the bootstrap.ini file that I can't write to and that
will be killed in the next update. 

This is how Firefox/Thunderbird do it and I think it's good.

If someone wanted a GUI to change that entry - why not? But IMHO that's not
necessary to make this proposal a progress against what we have now.

Being able to configure for several profiles is an additional benefit but
neither new (as I said, we can do that already) nor necessarily supported by GUI.

It seems, I do not understand the suggested changes.
I have now this scenarios:
(1) In my school I have changed the bootstrap.ini so that the OOo-user folder is
located in the users Home on the server (WinXP prof client, Linux server with
Samba). There are no entries in the Windows "Dokumente und Einstellungen" (I
don't know the English term) because the Windows user profile is mandantory
(ntuser.man) that means no new entries are persistent. Especially OOo has no
possibility to write to $SYSUSERCONFIG, as far as I see. The OOo-install folder
(with program, share, etc.) is located on the server, readable from all users
but not writable by normal users.
(2) As I test a lot at home (WinXP), I have got a separate folder in which I
extract the OOo install folder, and in which I locate the OOo user folder by
changing the bootstrap.ini. (My productive version with system integration and
default SO-user folder is a SO8.)

In both cases I actually have to edit the OOo bootstrap.ini with each
installation. How would that scenarios work with the suggested changes?

This would not be changed at all, I don't think that we should remove the
UserInstallation key in bootstrap.ini (that was Kay's suggestion). But by
default it should not be used and read from profile.ini instead.

This will help all those many users that - like me - prefer to have their
profile on another drive than c:

Instead of hacking bootstrap.ini they can do it in the profile.ini in their home
folder and they don't need to repeat that after each and every update.

You have to hack bootstrap.ini anyway - so it doesn't make a difference to you
whether the key by default does not exist or if you have to overwrite it.

Seems that I created some confusion here, so again:

1) It may be _me_ only, who thinks that the multiple profile support makes most
sense if supporting a reasonable dialog for their management. IMHO, this is an
end-user feature, everybody else can easily write a script to patch their
bootstraprcs(.ini) etc., only end-users have a problem with that.

2) If we are going to change the entry defining the "UserInstallation" variable
to be resolved wrt just another rc file, e.g. in the users home (~/.sversionrc),
than we may just want to clean this up and refer to the original entry in the
configmgrrc, this may safe some cycles while boostrapping.

But, as I have basically no stake in this, I leave it to you, to resolve this
issue (w/ or w/o a dialog etc. ;-) You may want to keep in mind, that multi
profile support can become a support issue.

      Kay