Re: [tdf-discuss] Automatic Updates

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

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

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

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,

Charles
-- 
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/