Date: prev next · Thread: first prev next last
2010 Archives by date, by thread · List index

 On 06/10/10 12:21 PM, Charles Marcus wrote:
On 2010-10-06 2:06 PM, Charles Marcus wrote:
Yes there is... use the MSI system, which will take care of things like
unpacking to the environments /tmp directory, launching the installer
after unpacking (like it does now), then - and here is the trickey part
I guess - detect a current installation, and offer to upgrade it, or to
install a parallel version.
Oh - and one thing that I'd really like to see is a simple 'incremental
updater' that just downloads a 'patch' file and patches itself, like
Firefox and Thunderbird and lots of other programs do now.

For the most part I agree with you. Where, I have a problem is with:
a) what MSIEXEC does
b) purpose/function of incremental updates

a) AFAIK, MSIEXEC doesn't enforce any kind of standards/best practices. Sure it does a lovely job of unpacking things and installing, but so do a lot of other 3rd party installer programs (NSIS, IzPack, Bitrock, et al.). Where these windows-based installers fail is that they do not guide or enforce a standard install methodology. Case in point is that the install path can be defined to whatever your heart desires. Sure you can use a predefined value to fill this variable (e.g. %programfiles%, %homedir%, etc), but there is no direction in the documentation as to what/where is the correct/best place - just suggestions. MSIEXEC is a means to an end - install methodology.

Granted, how LibO uses the windows install is put into question. And I agree, we(community plural) should be doing a better job. I know of other programs whose installers ask if you want to remove the previous installation. So it is possible. The capabilities are there to install/uninstall, but the update mechanism is up for grabs as several programs each have their own ideas about how to scan the WWW for and incorporate updates.

Which leads to...
b) In my original post I mentioned that any install should respect the package management of the base operating system. I still agree with this notion. And unfortunately, Mozilla breaks this mold. *nix users will run into permission issues if they try to update Firefox and/or Thunderbird from the program menus. Even Ubuntuzilla (a command line python script to perform updates) is external to Mozilla and needs permissions to perform an update. I agree an incremental update is a good idea, but to emulate these two programs I suggest is not the shining example of 'best of bread'.

The reason I object is that I have run into instances where entities external to Mozilla would hijack the install function placing plugins into the framework that the user either has no knowledge of and/or the installed code can only be removed through extraordinary measures (deleting from the command line/file manager). Lovely thought, but security becomes a major issue if we go this route.

Package management (i.e. such as apt, yum, rpm, etc) means the download is coming from a well defined location (you can trace the source) and is put into a specific format (deb, rpm, et al). Security is a factor in these methodologies and you can reinstall, remove/purge the package through the command line or GUI. Incremental updates are apart of this function.

OOo, and post-divergence - LibO, has an internal mechanism for updating extensions and itself. But this leads invariably to the situation I described above with Mozilla. Security and User Permissions then become serious factors. I agree that a better job of identifying an existing install and clean up is necessary.

Windows becomes the corner case...
There is no defined standard of where to install files, just suggestions.
And an update mechanism becomes an external program. There are 3rd party apps for updating sources. I believe we should explore those options.

Scott Furry

To unsubscribe, send an empty e-mail to
All messages you send to this list will be publicly archived and cannot be deleted.
List archives are available at


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.