Issue 84358 - setup doesn't care changes were made in bootstrap.ini of previous version OO
Summary: setup doesn't care changes were made in bootstrap.ini of previous version OO
Alias: None
Product: Installation
Classification: Application
Component: code (show other issues)
Version: OOo 2.3
Hardware: All Windows, all
: P3 Trivial (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
Depends on:
Reported: 2007-12-08 07:58 UTC by constchar
Modified: 2013-08-07 15:26 UTC (History)
5 users (show)

See Also:
Issue Type: FEATURE
Latest Confirmation in: ---
Developer Difficulty: ---


Note You need to log in before you can comment on or make changes to this issue.
Description constchar 2007-12-08 07:58:38 UTC
All Windows versions of (not 2.3 only) overwrite existing
bootstrap.ini without reading its content before and without saving of
parameters. So users who changed UserInstallation parameter (to keep OO's
personal preferences in network home directory for example instead of Windows
profile by default) must manually "repair" this file to use their saved
preferences. I guess it would be better to handle changes with care if it's
possible. And the best would be ask while installation where OO must save user's
personal preferences - in profiles or home directories
(%HOME%==(%HOMEDRIVE%|%HOMESHARE%)%HOMEPATH% in Windows domain environment)
Comment 1 Olaf Felka 2007-12-08 09:09:51 UTC
I've seen such a feature while installing Paint Shop and I think it's a good idea.
Comment 2 2007-12-10 10:57:55 UTC
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.
Comment 3 Mathias_Bauer 2007-12-10 11:12:26 UTC
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

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?
Comment 4 2007-12-10 11:25:40 UTC
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.
Comment 5 Mathias_Bauer 2007-12-10 12:41:23 UTC
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?
Comment 6 kay.ramme 2007-12-11 15:03:41 UTC
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.
Comment 7 Olaf Felka 2007-12-11 15:22:48 UTC
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?
Comment 8 Mathias_Bauer 2007-12-11 17:55:37 UTC
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.
Comment 9 Regina Henschel 2007-12-11 18:19:19 UTC
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.
Comment 10 Olaf Felka 2007-12-11 18:29:26 UTC
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.
Comment 11 Mathias_Bauer 2007-12-11 20:42:58 UTC
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.
Comment 12 Regina Henschel 2007-12-11 21:40:11 UTC
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
( 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?
Comment 13 Mathias_Bauer 2007-12-11 22:03:31 UTC
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.
Comment 14 kay.ramme 2007-12-12 08:19:36 UTC
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.