First, the safest way to avoid those problems on Windows is to install the OOo-dev 3.4 developer builds. These do not overload on existing OpenOffice.org installations.
If the system integration builds are used, they identify themselves as OOo 3.4 and this will indeed cause collisions. They might be reducible (see below), although the best solution, especially to help mitigate regression risks for early adopters, is for the Apache OpenOffice project to ensure that AOO 3.4 will install side-by-side with any other OOo-lineage product installation. I'm not sure that can be accomplished in the current drive toward a release candidate. Even the OOo-dev 3.4 might cause some collisions when it comes to file extension registrations and other things. I don't have enough configurations available to shake that out very well. However, I have seen no collisions in the few setups I have. This is not something I am looking at systematically. It is possible to direct the Windows Installer to do the installation in a different location on the machine, but this is only where it stores the installed run-time. Kay, I have attached screen shots that you will get in the direct copy. These won't appear on the list, however. COLLISION AVOIDANCE (EXPERIMENTAL): STEP 1: When the install reaches the "Setup Type" dialog, instead of accepting the default "Typical", click the "Custom" radio button and then click next. STEP 2: On the "Custom Setup" dialog that comes next, don't change the feature selections - they are initialized to the "Typical" settings. LOOK AT THE "Install to:" entry. It will be to a "Program Files" or "Program Files (x86)" subdirectory location. You can change this location by clicking the "Change ..." button. CAREFUL: Don't change the Program Files part. Just change the subdirectory part of the Install to: entry, ideally to a subdirectory that does not exist and needs to be created. WARNING #1: It is not uncommon for installs to fail when custom locations are selected. That is usually because something somewhere in the installation code or even the running application has a dependency on the default assumption. This is, in fact, something that needs to be a test case for Apache OpenOffice releases for Windows. WARNING #2: There remain prospects for collisions. There may be collisions with respect to user-installed extensions and with usage of user-specific locations (e.g., AppData) in the Windows configuration. Anything where the application name is the qualifier (OOo-dev 3 or OOo 3) will collide with that use by other builds/installs. This could be improved upon by using the dot-level (OOo-dev 3.4 and OOo 3.4 or, better, AOO 3.4, and using those in the Program subfolder locations too.) - Dennis -----Original Message----- From: Kay Schenk [mailto:[email protected]] Sent: Saturday, March 03, 2012 10:14 To: ooo-dev Subject: [TEST] procedures for no overwrites of existing OOo 3.3? Hello all-- I run Linux and know how to avoid overwrites with our current test packaging by using the "--prefix" option when I do an RPM install. And this is what I used for the test I recently did. Are there similar options available for Mac and Win users? It seems some of our testers are not happy with the overwrite of their existing version. If someone would forward instructions to me, I will add a new wiki page on "Testing Procedures". Thanks. -- ---------------------------------------------------------------------------------------- MzK "Follow your bliss." -- attributed to Joseph Campbell
