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

On Fri, Oct 8, 2010 at 4:05 AM, Scott Furry <scott.wl.furry@gmail.com> wrote:
> -> 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.
>
> Q01) Can we have repositories for LibO packages? (e.g. deb -
> apt.documentfoundation.org or rpm.documentfoundation.org)
>
> The idea about having a repository does not have to be permanent solution,
> but would allow downstream maintainers to pull/mirror packages for their OS
> community. LibO (and by extension DF) would gain credibility and good will
> in the community. We can start to build rapport and lines of communication
> with the PTBs in the different OS groups. Just a thought.

As Charles said, the proper term is "distribution".  Different
distributions use different binary and patch package formats, have
different versions of the libraries that openOffice builds on,
different supported processor types, different release schedules, and
different policies on software updates, and these even vary between
releases of the same distribution (which may need to be supported for
many years).  This greatly complicates matters.

There is also the issue with other software that may make use of bits
provided by openSUSE, this may break because of updates not approved
by the distribution (if there even is such software).

There are, however, tools like the openSUSE build service that make it
much easier to distribute native packages for many distributions.  I
am not familiar with the others, but a number of places, like
opendesktop.org websites and the Linux Foundation, are now using the
build service to simply the delivery of packages for many
distributions simultaneously.  So it is, at least, a popular solution.

However, distributions are still going to want to release their own
versions with their own tweaks, their own branding, and matching their
own release schedules and policies, so it may or may not be worth 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?

As I said, the buildservice could do this mostly automatically.
Distributions could also send their own versions back upstream to the
website, but if we were going this route it would probably be easier
and safer for everyone if the website just pointed users back to the
distribution's native version (since it would receive updates vetted
by the distribution).

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

The linux distribution packaging systems are not really an optimal
tools for distributing add-ons.  For one thing, they are almost all
system-wide, while many users might want to install add-ons on just
for themselves, and in corporate environments wouldn't be able to
install them at all.  So distributions can choose to ship extensions
through their package system, and some do, but I don't think using
this as the sole or even primary means of doing so.

As I mentioned before, the opendesktop.org website like kde-look.org,
gnome-apps.org, InkscapeStuff.org, and so on seem to be a better way,
to me, to distribute extensions, templates, and other add-ons.  The
websites are specifically designed for this, and they implement a
freedesktop.org standard called Get Hot New Stuff, or GHNS, which is
specifically designed to allow programs to search for, identify,
categorize, retrieve, and update add-ons.

They are used extensively by both gnome and kde for distributing
everything from wallpapers and color schemes to desktop widgets and
file manager extensions, and they appear to have a mechanism to filter
out results that are not compatible with the current version of
whatever program is trying to install them.

Rather than wasting the time and effort to design an entire new system
from scratch, I think it would be better to use an existing standard
tool like this, especially if the goal is to play well with the rest
of the open-source ecosystem.

> One last point I should make here - once a user installs a package, normally
> that user should continue to update via package management (dpkg, apt, yum,
> et al.) 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.

Someone pointed out in the previous thread that simply disabling and
hiding the update mechanism for non-root users would solve this.

There is still the issue with extensions installed via the package
manager and those installed on a per-user basis.  Ideally, the
software would check whether the current user has write permissions
for the extension.  If not, it would be grayed out or have some other
color, would disable the buttons to manipulate it, and would be have a
label telling the user he or she does not have permission to make any
changes.  Users would still need to be able to disable the extension,
but they could not uninstall or update it.

Another issue is what happens if the extension is installed by the
distribution AND by the user.  I would think the user version would
always have precedence, and the distribution version would be hidden
entirely as long as the user version is installed.

Perhaps, the user could update the distribution-provided extensions,
but rather than changing the distribution version it would download a
user-specific version, and this would take precedence.  The user
should probably be warned that this is going to happen.
> -- OS specifics of update and networking could be pulled out of the main
> LibO development.
> -- It would remove the problems of corrupting an install if not a superuser
> (packaged LibO wouldn't have separate updater program for Unix|Linux or if
> it was disabled by an ADMIN)
> -- a separate update program could then 'check-in' with the servers (once a
> week, once a month) to verify if updates are available (get permission from
> the user to shut down the current LibO instance, update, then start LibO
> back up)
> -- 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)

For windows, definitely.  For Linux, I don't see any advantage over
using the distribution's own package managers.  They have all of these
advantages, have the advantage of already been in use a long time and
have been thoroughly tested, and have the advantage of not interfering
with the distribution's packaging policies.  It would be rare, in my
opinion, for Linux users to even want to use such an updater.

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