Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing
|Summary:||NSIS: remove the directory after the NSIS is finished|
|Component:||code||Assignee:||AOO issues mailing list <issues>|
|Status:||CONFIRMED ---||QA Contact:|
|Priority:||P3||CC:||andre.schnabel, andrixnet, bettina.haberer, christian.jansen, cnospam, emmanuel.touzery, floeff+ooo, ingo.schmidt-rosbiegal, issues, kami911, khirano, mseidel, nesshof, olaf-openoffice, quetschke, stp, tuharsky|
|Issue Type:||TASK||Latest Confirmation in:||---|
Description pavel 2005-05-25 15:30:14 UTC
After NSIS installer is finished, the directory where it unpacked the whole tree should be removed.
Comment 1 pavel 2005-05-25 15:30:42 UTC
Comment 2 pavel 2005-07-29 00:02:36 UTC
Looks like it is on purpose. Download template setup_native/source/win32/nsis/downloadtemplate.nsi contains: Section -Post IfSilent onPostSilent onPostNoSilent onPostSilent: ExecWait "$INSTDIR\setup.exe -lang $LANGUAGE /qr -ignore_running" RMDir /r $INSTDIR RMDir $INSTDIR GoTo onPostDone onPostNoSilent: Exec "$INSTDIR\setup.exe -lang $LANGUAGE" Quit GoTo onPostDone onPostDone: SectionEnd And we are probably in "NoSilent". Why? Shouldn't we add RMDir /r $INSTDIR RMDir $INSTDIR to both branches? Or should we change to "Silent"?
Comment 3 Olaf Felka 2005-08-02 11:24:35 UTC
of @ mh: I don't think it makes sense to remove the installation source after unpacking. The setup modify and repair option needs these files and will fail if they are removed. Therfore I would consider it as a bug to remove these files.
Comment 4 pavel 2005-08-02 11:42:51 UTC
IIUC it is as follows: - if you want to run setup.exe manually something wrong hapenned and there is big probablility that it doesn't happen right after the successfull installation of OOo (only after successfull installation the unpacked directory is to be removed) - you do not have a chance to run setup.exe with different parameters from NSIS installer - right now, after finishing the installation, all people have to manually remove the directory where NSIS unpacked the source for the installation Q: Is it possible to run setup.exe with "setup modify or repair options" directly from the NSIS archive the same way as the correct installation is called? I'll answer to myself. I have just tried running NSIS installer again after complete successfull installation and removing the folder with installation files completely. NSIS installer started and I'm now offered with the following possibilities: - Modify - Repair - Delete (translated from cs back to en-US, so please try to imagine that dialog :-) So it looks like it is completely OK to remove the files (even after unsuccessfull installation), because setup.exe is intellingent enough. of: Maybe you were describing all this with not having NSIS in your mind? I do not want to remove OpenOffice.org_....exe file, but the folder with installation files (in my case, it was unpacked to Desktop).
Comment 5 Olaf Felka 2005-08-02 12:04:19 UTC
If you start the modify or repair option from the control panel 'Ad Remove Software' you've lost. The installer can't find the .msi file and fails.
Comment 6 pavel 2005-08-02 12:11:19 UTC
I do not use Windows at all, so my question might look funny to you: is it typical to copy DVD with the installation to the disk, install from there and *not* remove the copied installation files? If I understand you, you are writing that we have to leave the installation files on the disk too? In fact, yes, after removing the folder with unpacked installation files, I can't finish the installation's repair or modify. I have to run the setup/repair again from the NSIS .exe file.
Comment 7 Olaf Felka 2005-08-02 12:25:02 UTC
If the user installs from CD he usually knows that he has to insert the CD to continue with the installation. While the setup is running with a (re)moved installation source you'll get a messagebox the xyz.msi can't be found. The you can point to the msi file (if it has moved). If you have the nsis file only, you can't point anywhere to proceed.
Comment 8 pavel 2005-08-02 12:29:36 UTC
of: so in addition to install ~210MB on the disk, we will also ask user to keep 81MB directory somewhere? They'll kill us... I understand your technical reasons to leave them where they are, but I do not think people will follow the rule to leave files on the disk. I predict that 99% of all users will remove that directory after finishing the installation. This report was create on the feedback of one such user (not me ;-).
Comment 9 Olaf Felka 2005-08-02 12:40:43 UTC
If users do it they do it on their own risk. At least it makes more sense to remove the nsis file after unpacking just as it has been with the zip file before. And in times of 80GB harddisks.....
Comment 10 kami911 2005-08-02 15:13:52 UTC
Hmm, interesting question.... The windows installers usually do not store the full installer pack on the users's system. But if you use an msi based installer, it may require the availability of installation package. If you want to add/modify/and sometimes remove the setup of OOo it may require the unpacked installation set. So option without deleting is would be nice. But the mass of users will remove that unpacked install set. In onther hand if you start the distribution package it will start the setup again and ask for option (modify/repair/delete). The best solution would be if the users can make the dicision about deleting of unpacked file. You can review my way regarding this question: http://qa.openoffice.org/issues/show_bug.cgi?id=51780 Executable example: http://www.openoffice.org/nonav/issues/showattachment.cgi/27825/OOo_1.9.106-en-US.zip Hey, KAMI
Comment 11 kami911 2005-08-04 07:26:37 UTC
Another solution is to add command line interface. It does not require new ui strings. For example if we specify /remove options for the installer it will remove the unpacked installation package... AFAIU the current situation is when you specify: /S runs the installer or uninstaller silently. See section 4.12 for more information switch the pre-installer will remove the unpacked files. One note: The lines: RMDir /r $INSTDIR RMDir $INSTDIR is very very dangerous. That is why it step forward to InnoSetup (and for another hundred reason). If you add a system like folder as extraction path it will delete them all... We should avoid this type of attack :o)
Comment 12 pavel 2005-08-04 09:02:18 UTC
kami_: command line options are useless for typical user. He will simply click on the exe file. Nothing else. We have to solve the situation for such user, not for users who can run that installer from command line...
Comment 13 pavel 2005-08-04 10:08:45 UTC
Adding Ingo to CC:.
Comment 14 ingo.schmidt-rosbiegal 2005-08-04 12:36:06 UTC
We have discussed this problem when we introduced the nsis installer. And it is true. For the Windows Installer the installation set is stored in that directory, where nsis unpacked it. Therefore this installation set cannot be removed because of the maintenance mode. But this is not the CD problem. The nsis installation sets shall not be located on a CD. There we use the installation sets without nsis. And in this case in maintenance mode the CD is required. The nsis is only used for downloads. And in this cases the user has no CD and threrefore needs to have the installation sets for the maintenance mode on his harddisk.
Comment 15 pavel 2005-08-04 15:06:02 UTC
Ingo: I think the decision was wrong. I think much better way would be: - disable Change/Repair in the Add or Remove Programs dialog *or* create simple app to be called and display "Please run Repair/Modify option from the installation set." - remove unpacked installation files after NSIS is finished But as I already said: I'm no Windows expert. Only my logic tells me that installing 80+210 MB instead of 210MB is not the best solution. And the only reason being critial case of corrupted installation and the fact that the installation can be Reapired/Modified from the new run of NSIS .exe file.
Comment 16 pavel 2005-08-08 20:36:05 UTC
Volker: what is your opinion?
Comment 17 quetschke 2005-08-09 06:09:40 UTC
Greetings from Zion National Park, Utah :-) > But as I already said: I'm no Windows expert. Only my logic tells me that > installing 80+210 MB instead of 210MB is not the best solution. Yes, but it's "only" 33% more. We could warn the user and say something like: "You can remove the unpacked installation files <put directory here> and gain 80 MB of harddisk space but you will lose the ability to select Change/Repair." at the end of the NSIS installation. > And the only > reason being critial case of corrupted installation and the fact that the > installation can be Reapired/Modified from the new run of NSIS .exe file. can't ? Yes, that is unfortunate. I really don't care that much about the extra harddisk space and I think the majority of users will not download the nsis package but install the release version from some CDs/DVDs that inevitably will be found in computer magazines.
Comment 18 stp 2005-08-10 17:10:22 UTC
pjanik: You wrote Tue Aug 2 03:42:51 -0700 2005: - you do not have a chance to run setup.exe with different parameters from NSIS installer I don't know if this is what you meant but command line parameters can be passed from e.g. nsis.exe -p to setup.exe -p by using a premade function: http://nsis.sourceforge.net/wiki/Get_command_line_parameters Example available in the script in issue 4729.
Comment 19 pavel 2005-09-16 12:38:44 UTC
change target to OOoLater. I still think that repair can be done by downloading the same NSIS .exe file again from the Internet (aka "inserting the CD back").
Comment 20 Olaf Felka 2005-09-16 17:31:04 UTC
I think that 'You want to repair you office but you can't because of NSIS has deleted your files so download again the whole stuff and sorry if you only have a modem?' isn't a solution. I don't think that we should delete these unpacked files. Forcing someone to redownload is a mess and not offering a repair or modify also.
Comment 21 andreschnabel 2005-09-18 22:02:12 UTC
andreschnabel->pjanik: all your concerns about wasting diskspace is easy to resolve, esp. when installing from disk: don't use NSIS package. Put the plain (unzipped) msi Installer on the disk and be happy. We can prevent most of the problems named here, when making NSIS not the default: - no need to remove temporary install files - no need to write special commandline interface - easy reinstall / repair from original setup or windows control panel. But .. for the current issue: If you provide NSIS and don't want to leave setup files after installation, just make it optional and tell the user what they might be usefull for.
Comment 22 kriz05 2005-09-23 00:38:43 UTC
I think the best way to handle the issue for 2.0 would be: 1. unpack to temp folder 2. install by calling setup 3. change HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\PRODUCTC ODE\ModifyPath to nsis installer exe 4. delete temp folder Step 3 should be implemented inside downloadtemplate.nsi (I've never used NSIS but I'm sure it's possible) If some user selects AppWiz's modify/repair option then the downloaded nsis installer gets called offering all possibilities.
Comment 23 arthit 2005-09-24 12:03:29 UTC
Location: IF we really have to use NSIS, and the directory is really unmovable/undeletable, then please put it somewhere else, NOT on the Desktop. It can be in the /Windows folder, or newly created /Program Files/OpenOffice.org/setup or anything that is NOT the Desktop. Q: Why ? A: Periodically, Windows XP will ask the user to clear out unused icons (documents/folders) on the Desktop (or eventually it automatically do that for the user) -- so the path will broken. (and this is a worst case scenario, Wasted disk space AND Cannot repair the setup -- at the same time!)
Comment 24 Olaf Felka 2005-10-27 08:37:36 UTC
*** Issue 56747 has been marked as a duplicate of this issue. ***
Comment 25 kami911 2005-11-22 01:34:34 UTC
What about to put Installation files into defaultly a folder under root drive like this: C:\Installation Files\OpenOffice.org<version> Pros: It easy to locate it under Windows, Not dependent on one user's profile, MOS2003 do the same thing But we have to create the way to remove those files after the installation in the Preinstaller.
Comment 26 Olaf Felka 2005-11-23 08:30:41 UTC
The easiest way to locate a folder is to place it on the desktop. If the user thinks that "?:\Installation Files\OpenOffice.org<version>" will be better he has the chance to change it.
Comment 27 kami911 2005-11-24 22:57:22 UTC
OK, I must agree :o)
Comment 28 floeff+ooo 2005-12-11 17:47:52 UTC
Please keep in mind that for distribution software on a Windows network, getting access to the plain MSI files is *A MUST*. Anything else is just a pain in the ass. Looking at the fact that we currently don't have a transformation wizard for OOo, but only for SO8 (on the enterprise CD), network installation doesn't make much fun at the moment. But if getting the plain MSIs will get harder (i.e. running installer and then getting the MSIs out of the temp directory), this is no option. At least, please offer a ZIP download so one could get the MSI packages.
Comment 29 Olaf Felka 2006-03-08 08:44:08 UTC
*** Issue 62883 has been marked as a duplicate of this issue. ***
Comment 30 atdsm 2006-03-08 13:39:06 UTC
I opened an issue about this in issue 62883 (now marked a duplicate), but then I was pointed to this issue. I will therefore post comments here. If I may add some comments from a user's point of view: -To a user, I would guess that the "repair" thing is not their first thought. (It wasn't mine.) The first thought is, "why didn't OOo delete these files? We don't need them anymore." -In other words, unzipping the files on the Desktop and then leaving them there looks to the user like OOo didn't clean up after itself. Users like me are likely to delete the files themselves to free up space. Then, the "repair" option won't work AND it is a nusaince to the user to have to delete the installation files manually. -Unzipping the files elsewhere hides them from the user and is acceptable. But this can still start to use up drive space quickly if the user keeps installing new versions of OOo. This is especially true for QA volunteers who install the next release every couple of weeks. 80 MB is not a lot of space, but 80*10 = 800 MB is a full CD's worth. As a QA volunteer, I can easily accumulate that much space used in 4 months of OOo development releases. Maybe a solution would be to have the installer remove previous installation files? Maybe it already does this? I always delete them myself, so I don't know, but it seems like if the installation files might be anywhere, the installer wouldn't know where to delete old installation files from. -If repair is a concern, can OOo ask up-front where OOo itself will be installed (not just where the installation files will be unzipped), then unzip the installation files to a subdirectory of the target directory? Then the installation files are always available for repair and always in a standard location. Also, the user does not have to get the unsightly files off his/her desktop. -For example, first screen shows "Where would you like to install OpenOffice?" and has a target "C:\Program Files\OpenOffice.org\". Then, the installer unzips to "C:\Program Files\OpenOffice.org\Repair\" and runs setup from there. Setup then installs to "C:\Program Files\OpenOffice.org\" automatically, without asking the user a second time where the program should be installed. I am not a programmer, so I don't know how feasable this is to do. But it would be nice for the end user to not have to worry about it. -Alternatively, you could just make it optional for the user to delete the files after installation. For an visual representation of this, see my attachment to issue 62883. Steve
Comment 31 Olaf Felka 2006-03-23 12:10:14 UTC
We should even think about deleting the compressed download file. This is useless after uncompressing it and can be removed.
Comment 32 emmanuel_t 2006-12-21 07:13:27 UTC
what is the probability of the user needing to use the "repair"? This behaviour is looking very unprofessional (what users see is, OpenOffice is leaving temporary files around, and even worse, on their desktop). And in the extremely unlikely situation that the installation would need a repair, 99% of people wouldn't know that they have a repair option in the add/remove programs (and then there is the question of the probability of the repair option to work). And I'm expecting to see many computers with folders "OpenOffice 1.0 installation files" "OpenOffice 1.1 installation files" "OpenOffice 2.0 installation files" "OpenOffice 2.1 installation files", and so on. These are "system files" that users won't dare to delete "it might break something" and will stay there forever. Which means, this is wasting much more than 33% of disk space, and much more than 80Mb. In any case, of programs with downloadable installers on the internet, I think OpenOffice is absolutely the only one with this policy. firefox not, opera not, thunderbird not, winzip, inkscape, gaim, filezilla, blender, etc etc etc... not. I'm not sure about Acrobat reader though. I think at the very least the installer needs a checkbox "Keep installer files on disk for repair option (uses 80Mb)". But if the user downloaded the file from internet the first time (even using dialup), it's not shocking to ask them to do it again in the extremely unlikely case that they'd need the repair option. In the real world, dialup users will get OO from a CD and it won't be a problem for them to reinstall it, and users with a fast connection won't have a problem reinstalling.
Comment 33 Olaf Felka 2007-04-16 10:11:28 UTC
*** Issue 76237 has been marked as a duplicate of this issue. ***
Comment 34 kami911 2007-10-05 08:08:18 UTC
@ emmanuel_t: I think at the very least the installer needs a checkbox "Keep installer files on disk for repair option (uses 80Mb)". THis can be a good movement. Let's the user decide what he really want.
Comment 35 Olaf Felka 2008-02-13 17:01:23 UTC
*** Issue 85113 has been marked as a duplicate of this issue. ***
Comment 36 timwi 2008-02-13 17:43:24 UTC
> I think at the very least the installer needs a checkbox "Keep installer files > on disk for repair option (uses 80Mb)". I agree with this sentiment, but I strongly recommend NOT to place those installer files on the desktop, or indeed anywhere else the user might perceive as intrusive. The correct place for these files is the program directory because these files pertain to the program and nothing else on the system.
Comment 37 Olaf Felka 2008-02-13 18:02:20 UTC
These filed *do not* belong to the program so they don't have to be placed in the program folder. These files belong to the installation. This is *not* the same. Where else then the Desktop to place these files? Nothing is more intuitive than the Desktop. And as said, the user can change the path while extracting. And a 'self destroying' function for an installer I've never seen. For me it's a lot of noise about a minor problem.
Comment 38 Olaf Felka 2008-02-13 20:11:07 UTC
*** Issue 85113 has been marked as a duplicate of this issue. ***
Comment 39 andrixnet 2008-02-14 09:26:27 UTC
of: I'm sure I'm repeating something that has already been said : 1) Why an installed inside another installer? NSIS is a very versatile and powerfull installer, it could perform the entire process. Windows installer could also work out of a single self extracting archive. Again, why an installer that just unpackes another installer? - to increase the duration of the installation process - to use up double the disk space then the initially downloaded installer - to leave almost 100MB of files somewhere on the disk (user's desktop) - hassle the user to manually delete a bunch of installation leftovers something installed with MSI also copies parts of the kit as a MSI file somewhere inside c:\windows for it's Modify/Repair feature, why can't OO (assuming this is an issue) do the same, instead of leaving the entire kit on the desktop? and besides, leaving it on the desktop is like asking for the user to manually remove it, then any modify/repair functionality won't work any way! besides, it's not that much of an effort to uninstall it completely and put it back in. and with the fairly frequent version updates, what the hell would I need a repair option? Just install the latest one, or the initial one, whose kit I saved somewhere... user's prefs are savedin homedir, right? so a reinstall cycle won't affect the user. I've seen (fortunately only a few) uninstallers that requested the original instalation kit (usually the cd) for it to perform just uninstall (forget the modify/repair this time) and IMO I felt such a combination to be the worst possible idea.
Comment 40 ingo.schmidt-rosbiegal 2008-02-14 22:44:58 UTC
is -> andrixnet: Please do not mix up different things. For the problem, that we have to keep the installation set on the system, it is not important, if we use a wrapper around the installation set or not. For the OpenOffice.org installation we use the Windows Installer service, nothing else, and this will surely not be changed in the near future. To simplify the download mechanism we introduced a wrapper by using nsis. We could also use a simple zip or a selfextracting exe or whatever. This would change nothing to this problem. After the Windows Installer installation set is successfully unpacked on your system, it is started from this position on your system. And exactly this position is important for the maintenance mode like repair or adding components (for removing components or the complete product the installation set is not required). You could for example first install Writer and Calc and later decide that you also want to use Impress and Draw. For such a scenario you need the source files again. And Windows Installer "knows" where to find it, because it saved the location of the original installation set. The CD scenario you mention ("please insert the CD") works for OOo fine, but of course you have to install OOo from the CD, not from your local hard drive. So you simply have to use a CD containing OpenOffice.org or you have to download it, use the nsis wrapper only for unpacking and burn the installation set on a CD. Then you could start the installation from CD and if you later want to repair the installation or add components, Windows Installer would tell you "Please insert the CD." But in our scenario the Windows Installer "knows" that OOo was installed from <somewhere_on_your_local_hard_drive>. If we remove the installation set after the first successful installation, this must lead to an error in maintenance mode, because the Windows Installer knows that the installation set is no longer available. In this error dialog you can select a new path to the installation set. So if you burned it on CD before removing it, you can now also use the CD. But this is surely not what we want. If you say, that "Repair" is not so important, well okay, we could discuss about it. But I think, that adding components is not so unusual. So I think, that we are not allowed to remove "Change installation" in maintenance mode. But to stress it again. This has nothing to do with nsis or any other wrapper we could use to simplify the download. Even if we include all cabinet files into the msi database and use a one file Windows Installer installation set without any wrapper: You have to start the installation from your local hard drive and the installation set has to be saved exactly at this place.
Comment 41 rs387 2008-02-15 09:27:55 UTC
I have about 50 different pieces of software installed on my PC. Can you imagine my desktop if every program did what you guys are doing? The desktop is MINE and I really hate programs leaving their stuff there without my permission. What makes OO _particularly_ bad is that unlike shortcuts, I can't just delete or move the files without breaking some dependencies. Another reason not to leave YOUR setup files on MY desktop. In corporate environments the desktop is often stored in the roaming profile. The roaming profile disk space quotas can be fairly restrictive. Another reason why this is a bad default. MS Office leaves the setup files on the PC as well. Where are they? I don't know and I couldn't care less. I'm sure 99% other users don't care either. They are not on the desktop, they do not interfere. By leaving them on the desktop you REQUIRE the users to care. Leave them somewhere if you have to but not on the user's own private personal space! (MS Office installer is also kind enough to tell you that it's left X megabytes of files which it could delete for you immediately if you don't want them.) SUGGESTIONS: 1. Offer the user an option to delete the files at the end of the install process. 2. Store them _wherever_ you want OTHER THAN my Desktop and My Documents. C:/Windows/$MyProgramsInstaller$ seems to be a common place for these things.
Comment 42 andreschnabel 2008-02-15 09:38:11 UTC
quote: "I really hate programs leaving their stuff there without my permission" Actually you gave OO permissions to use your desktop. The installer offers the option to unpack wherever you want. But -agreed there should be an option to remove the files after successfull installation (but this was mentioned previously here). Making the same claims again and again doesn't help at all.
Comment 43 Olaf Felka 2008-02-29 14:15:24 UTC
Comment 44 ingo.schmidt-rosbiegal 2008-03-03 09:52:22 UTC
I just enable in cws native133 usage of modern nsis versions, like nsis 2.3.5. And I also like the suggestion in task i66883, to add a checkbox to the directory selection dialog, in which the user is asked to remove the installation set at the end of the installation. Can anybody make a patch, in which the checkbox is added to the existing directory selection dialog?
Comment 45 ingo.schmidt-rosbiegal 2008-03-03 09:56:04 UTC
Ah, I mean i62883, not i66883.
Comment 46 deaconctk 2008-03-03 15:16:04 UTC
Having a checkbox is nice, but does not really fix the problem. If removing the installation files breaks something else, then this practice should be discouraged--or at least the user should be warned about the ramifications of such a choice. Providing the option is a great idea, but the default location still needs to be somewhere other than the desktop. I regularly use Windows 2000, XP, Fedora, Ubuntu, and--less frequently--Solaris. I don't recall ever seeing any program other than OOo using the desktop as the default location for the installation files. What I do see frequently under Windows is the option to change installation directories--along with a warning recommending that you keep the defaults. I have learned the hard way that changing the defaults often results in problems when it comes time to upgrade, repair, or uninstall. Consequently I (and I suspect most users) hesitate to change the default directory settings during installation. But here's some numbers. I found 218 .msi files on my Windows XP laptop: 74 under C:\dell\Drivers 11 under C:\Documents and Settings (only 7 unique files) 2 under C:\i386 11 under C:\Program Files 120 under C:\WINDOWS A further breakdown of that last 120: 4 under C:\WINDOWS\Downloaded Installations 2 under C:\WINDOWS\Hewlett-Packard\Setup Files 107 under C:\WINDOWS\Installer 5 under C:\WINDOWS\Microsoft.NET 2 under C:\WINDOWS\System32 Of the 11 under C:\Documents and Settings, 5 of them are duplicates--one in each user's directory, plus one under Default User. So there are really only 7 unique .msi files under C:\Documents and Settings. (OOo did not come up in this list since I naturally deleted the installation directory.) Most are under C:\WINDOWS. But there is clearly a precedence for using C:\Program Files. Using C:\Program Files also makes it clear at a glance what program the installation files go with. An alternative would be to follow the HP example and utilize C:\WINDOWS\OpenOffice.org\Setup Files (or something similar). I know that OOo is a professional quality product. However, sticking with the Desktop as the default installation directory makes OOo seem very unprofessional and makes it very HARD to "sell". It gives a bad first impression to users, system administrators, and others who are considering migrating to OOo.
Comment 47 kami911 2008-03-03 15:32:31 UTC
Hi! I hope I can provide patch, if we decide what we want. I suggest to create such checkbox? [x] Keep installation files after the installation For location: If install as administrator we can put it to: C:\WINDOWS\Downloaded Installations As a simple user we should keep these files in the users profile. Another point of view: We can alway put the installtion files to: C:\OpenOffice.org.install\[version] folder for example
Comment 48 deaconctk 2008-03-03 16:48:50 UTC
I should have noted that the 11 installation files under C:\Documents and Settings were under either username\Local Settings or username\Application Data. (None were on the Desktop.) With the default installation of recent versions of Windows (XP and later), I believe you have to be a computer administrator in order to install programs, so I don't believe we have to worry about simple users doing an installation. That is, assuming default folder protections and such haven't been modified, then if the user has access to install a program under the Program Files folder, then he has access to save the installation files anywhere! (A possible exception might be installing a user profile to access an existing network installation--but that's not really installing OOo.)
Comment 49 Olaf Felka 2008-07-16 07:19:14 UTC
*** Issue 91689 has been marked as a duplicate of this issue. ***
Comment 50 zcat 2008-07-16 08:37:07 UTC
My own 3c. 1c) I consider leaving a folder full of install files on the desktop absolutely AWFUL. I don't care what the reason. If they must be left (which I find highly questionable, see 2c) at least put them somewhere out of the way, not in My Documents and certainly NOT on the Desktop. Let me say it again. AWFUL. 2c) Repair? I have not yet encountered a single Windows user who was even aware that there is a 'repair' option, ever. Let alone used it. If any installed program becomes broken they all simply run the installer again from the CD or wherever. And in the unlikely case that some user expects a repair option and can't find one, I'm sure running the installer again would be the next most obvious action. 3c) Having an installer within an installer on the CD seems totally pointless, and adds a big long delay which causes most users to assume the CD didn't autorun and go looking for it in My Computer, and then get twice as annoyed when two installers pop up because they manually ran a second one when the first was quietly loading itself into ram. I've been remastering the CD image before I give it to people so that it simply runs the 'real' installer from the beginning. No delay. No messy folder on the desktop. If they need to repair they can just put the CD back in. If they ever have to repair, it's probably time to upgrade to the next version anyhow.
Comment 51 Olaf Felka 2008-07-16 09:07:05 UTC
@ zcat: 1c) Everyone has the chance to change the location where these file should be stored. 2c) If you haven't encountered that anybody uses this function doesn't mean that nobody uses it. It's a common feature that the Microsoft Installer offers. Rerunning the setup doesn't make a difference because it will also offer the repair. But that will also not be possible if the installation files are deleted. Following your suggestion the user has to uninstall and reinstall his Office. *That* is a bad user experience. 3c) Is a different problem for different project that should be addressed in a new issue. It's not an installation problem but a distribution issue.
Comment 52 Martin Hollmichel 2008-10-06 07:48:54 UTC
Got a lot of feedback that after downloading OOo start's it installation process again and again. It seems to be bad user experience that after first installation there is a new "something" on the desktop which does not the expected thing. We really should remove this behavior therefor I set target 3.1 for this issue. I also see not the need to create a backup of the installation files, either the user can store this by his own action separately or get it again from the original medium (CD, Internet). reassign to UX for final say.
Comment 53 floeff+ooo 2008-10-06 09:41:52 UTC
Please also do think of poor admins who need their MSI files and leave an option to extract all files from the setup EXE to a directory, like setup.exe /extract:c:\filestore\ooo31
Comment 54 ingo.schmidt-rosbiegal 2008-10-06 09:56:20 UTC
There are already many existing options in the download installation sets, like only unpacking or remove after unpacking, or unpack into dir xyz, or ... . Please have a look at this parameters using setup.exe /HELP=ON
Comment 55 andreschnabel 2009-04-04 19:44:40 UTC
seems noone has done anything - change target