When trying to do a parallel install I found that the MSI installer for 3.5.0 RC2 (and RC1 as well) doesn't report errors and proceeds with installation ignoring permission errors. See this topic for details: http://nabble.documentfoundation.org/Windows-parallel-install-tp3692947p3692947.html The MSI installer in Kendy's daily builds reports errors and stops, as expected.
I modified Version due to report. I have done lots of lots of Server installations without having seen any problem on WIN XP 32 Home and WIN 7 64 Premium Home @Pedro We need much more information: "doesn't report errors"? What errors? "ignoring permission errors"? What permission errors do you see? Why do you expect that that's a LibO problem and not a MS mxiexec.exe problem (if a problem exists)? What are the system settings for your device "D:"? Is that really a new problem or is it a general problem you see on your PC Please try a server installation with an old Master version, may be also a 3.3 or 3.4 with a setup.exe
> I have done lots of lots of Server installations without having seen any > problem on WIN XP 32 Home and WIN 7 64 Premium Home So have I until now. I can't test any further because I corrected the problem that caused the error message. The situation here is that if the installer is directed to a folder for which the user has no write permissions, it will still be installed there but it won't allow the user to modify the files (and therefore LO can't run as a TRUE parallel install from that folder since it can't create the Data folder) Maybe this bug has always been there (I can't test back) but this would mean that it was always wrong. Warnings should be activated like in Kendy's msi installer. This is the expected error message (in this particular case) "Internal error 2203, <path to target .msi>-2147287035 http://support.microsoft.com/kb/324852/en-us
@Pedro: what the heck is "Kendy's msi installer"? ;-) For me it would help if you would create a clear, simple and short list with - expectations concerning installation behavior - with evidences why that should be expected - how exactly LibO.msi (not mesiexec.exe) breaks the rules My questions: a) do you see differences installing different versions (Master, RC, old setup.exe versions...)? during a server installation b) if yes, please describe exactly c) I believe a doubleclick on an installer.msi will run msiexec.exe without any parameter, may be the /a parameter makes the difference? Until now i see no indication for a problem in the LibO.msi. d) what is your experience doing Server installations for other programs (it does not matter whether they will run, only the installation process is interesting
Kendy told me that he did not do anything special, his tinderbox builds the installer the same way. However, your workflow is somehow not ideal. > if the installer is directed to a folder for which the user has no write > permissions, it will still be installed there but it won't allow the user > to modify the files This is true, you create an administrative install image with msiexec /a, by a side effect it is runnable. Installer runs with administrator privileges. > and therefore LO can't run as a TRUE parallel install from that folder > since it can't create the Data folder) This is false, because Data folder can be anywhere, it is not necessary to have it under the same folder. Why don't you put your Data folder to somewhere that your normal user can write, or why don't you create your administrative install under a user-writable directory? In my opinion it is not a bug, unless I did not understand your problem correctly.
@Rainer: this installer is not comparable with 3.4.x or 3.4.x because version 3.5.0 was the first have an MSI installer only (no exe, no extraction, etc) (In reply to comment #4) > This is true, you create an administrative install image with msiexec /a, by a > side effect it is runnable. Installer runs with administrator privileges. Why does Kendy's installer pop an error message warning about this and the RC installer doesn't? > > and therefore LO can't run as a TRUE parallel install from that folder > > since it can't create the Data folder) > > This is false, because Data folder can be anywhere, it is not necessary to have > it under the same folder. Why don't you put your Data folder to somewhere that > your normal user can write, or why don't you create your administrative install > under a user-writable directory? Is it false? And how do you edit the bootstrap.ini to change the Data folder location? I *was* creating the administrative install in a user-writable folder. The fact that it had an error only showed the problem. That is not the issue. > In my opinion it is not a bug, unless I did not understand your problem > correctly. The bug is that the installer doesn't provide an error message in a situation where it should (and where another installer does). Anyway I can't test this bug any further so if you want to dismiss it as NOTABUG, it's fine with me.