Re: LibO Install/Update ( was [tdf-discuss] Automatic Updates)

On 2010-10-08 4:05 AM, Scott Furry wrote:
> Hello all,
> I'm thinking the its time to dig out of the weeds/details and make
> this a more meaningful discussion for everyone [edit: about automated
> updates].

<snip>

> So,lets start with the Unix|Linux crowd:
> -> Package Maintainers (I like 'specialists' but let's use the term 
> people recognize) can build and distribute both installs and updates
> to different OS users. We are respecting the OS and working on the OS
> in a way with which people get taught/learned/accustomed to use the
> OS.

Instead of 'OS', I suggest we use 'distro' - because while most distros
being discussed are either Linux or BSD, there are a lot of different
ones and it isn't a one size fits all. So though they are the same 'OS',
they still have different package managers and/or maintainers.

> Q01) Can we have repositories for LibO packages? (e.g. deb - 
> apt.documentfoundation.org or rpm.documentfoundation.org)

A question I'd like to see addressed by one or more developers is:

How much of developer resources are consumed by providing the current
packages they provide?

If it isn't a lot, then I see no reason to change it.

> Q02) If there are people in the community that are good at this,
> would it be a bother for them put up the binary packages to the 
> documentfoundation.org servers?

See question above...

> Q03) Could extensions be lumped in with this topic? (to ensure
> future OOo extensions don't cause LibO grief as the two projects
> start to diverge)

Dunno enough about how the extension manager works, but absolutely there
needs to be a way to check for extension compatibility issues when
updating - update them if necessary/available, or disable them if the
current version isn't compatible and there is no compatibility update
available. Again, mozilla does this well (but could be better).

> One last point I should make here - once a user installs a package, 
> normally that user should continue to update via package management

Depends on how they installed from the package manager to begin with.
Please don't forget the fact that some people actually do install from
source.

> However, OOo and post-divergence LibO has a built-in updating
> mechanism. Great for Windows users but lousy for others where
> superuser/root permissions are required.

See above... the built-in updater would be fine for those who install
from source - because if they know enough to install from source, they
know enough to only run the updater with root perms - and the updater
itself should still check to see if it has the correct perms before
proceeding with an update (just check what perms are set on the
installed location, and compare to what perms the updater is running
with) - or, even better, allow it to prompt for the root password to
allow the updater to run as root.

> Q04) How hard would it be to pull out the Update Mechanism and make
> it a stand-alone program?

A better question is, should you... and I say it depends on what makes
the most sense from the developer standpoint. It seems to me that just
providing a native way (compiler option) to disable it completely is
easiest. Regardless, for Windows builds, the auto-updater should be
included as it is now.

> Q05) Can the current install be cleaned up?
> Users cited having left over files on the desktop and not being
> aware that one has to uninstall the old version to install the later
> version (big PITA in my books).

True... but easy enough to fix if/when the auto-updater is fixed to
actually perform updates as opposed to simply downloading them.

> Q06) Do we have people that can work on the Windows Installer?
>
> Now...as for my left over question above...I believe that a separate 
> 'Update Mechanism' independent of LibO would be a boon for a variety
> of reasons.

My recommendation (regardless of whether or not the updater is broken
out into a separate package):

1. add the ability to simply disable the auto-updater at compile time,

2. recommend in the packaging docs to enable this flag when package
   managers are building packages for their repos

3. improve the current update notifier (since that's all it is right
   now) so that it actually installs an update with minimal use
   intervention required (similar to the way mozilla does it now), and

4. determine the most standard, stable way to provide a native
   compressed .diff type patch file for use by the auto-updater to
   minimize the number of bytes needed to perform updates

> -- It would remove the problems of corrupting an install if not a
> superuser

Silly - as I said above, the updater should simply be smart enough to
detect this and refuse to try to update anything if the update will fail
(or allow it to elevate its perms).

> -- and the really cool idea...plays into Charles' idea of enterprise 
> installation.
> A separate install program that is:
> - scriptable ( can install/update many computers via a script)
> - allows local or remote repositories to be identified
> ( a corporate IT Admin downloads behind his/her firewall and users 
> update from that local store rather than reaching out to the
> internet)
>
> Q07) Does this seem a useful way to push into enterprise/group usage
> of LibO?

I appreciate the effort you're making here Scott, but regretfully the
answer is no, for one simple reason - it is reinventing the wheel.

There already exists a way for corporate environments, and it is called
GPO (Group Policies). The Sys Admin decides when updates are applied
(after testing), and pushes them out via GPO.

As an aside - I still need to test if the Administrative Installation
Point capability that existed in 2.x still works - does anyone know?

So, the effort would be better spent adding support for GPO. Of course,
since .msi installer support is necessary for GPO support, the windows
installation routine must be re-written from scratch anyway, so yes,
absolutely, during this process it should be cleaned up.

-- 

Best regards,

Charles
-- 
To unsubscribe, 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/