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

Hi Scott,

Thanks for the insightful comments...

On 2010-10-06 5:21 PM, Scott Furry wrote:
a) AFAIK, MSIEXEC doesn't enforce any kind of standards/best

I'm not sure I see your point. That doesn't mean that whoever codes the
.msi installer cannot code it to work as I have described. Yes, it means
they will actually have to tell msiexec precisely what to do, but is
that really all that bad of a thing? But ... (see below)

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

If it will work better, and more importantly, be easier for the devs to
accomplish the goal of incremental updates, I'm all for it.

One caveat though - .msi installers are required (I think) if you want
to incorporate GPO (Group Policies in windows domains) support, and that
is something else that I'd dearly love to see. Can these 3rd party tools
generate .msi files, or at least installers that will work with GPO?

Where these windows-based installers fail is that they do not
guide or enforce a standard install methodology.

While I agree it would be nice if they did, all that would effectively
mean is less work for the people writing their .msi installers (they
could use internal calls/routines and not worry about where to put
stuff, performing clean-up, etc).

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 

All true - but again, I don't see anything that prevents whoever is
writing the .msi to do so successfully and in such a manner as it will
work reliably in all Windows environments.

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'.

I agree, but the problem here is that the individual package managers
should be *disabling* the internal updaters in their packages, so that
they can only be updated using the package management system. This way
the internal updater would only work for someone who installed from
source, and whether or not it works properly would depend on the one who
installed it installing it in a location where the app has the
appropriate permissions and can successfully update itself.

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.

There must be a certain level of trust where package managers are
concerned. If a packager does something stupid like this, then that
systems users to scream bloody hell. The responsibility of the LibO devs
would end at simply providing the standardized diff.

This would not be an issue for anyone installing the official LibO app,
since the LibO devs would have full control of the process, both install
and updates.

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.

Fine, so use them... my main point was incremental updates, not doing it
using the application updater (guess I could have been more clear on
this point).

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...

Fine, let it be the corner case where the internal updater is used.

The mozilla auto-updaters work *great* on Windows, so the LibO
auto-updater should be able to do the same (if coded properly).

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.

I vote for 'whatever works', as long as the efforts will also work
toward full support for GPO... :)


Best regards,

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.