Re: [tdf-discuss] Automatic Updates

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

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.

Regards,
Scott Furry


--
To unsubscribe, send an empty e-mail to discuss+unsubscribe@documentfoundation.org
All messages you send to this list will be publicly archived and cannot be deleted.
List archives are available at http://www.documentfoundation.org/lists/discuss/