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


Quote attributions got messed up - sorry...

Again, I have to go back to my earlier posts - Mozilla is not the
shinning example.

Their incremental updater works very well on Windows - and with the
Update Notifier extension, all updates can be made pretty much silent
and automatic.

For any Firefox user, type "about:plugins" into your search bar and see
what comes back. You will find that MS has (more often through Windows
Update) installed ActiveX,

Eh? ActiveX in Firefox? Methinks you typed without thinking... ;)

Silverlight, .Net Framework plugins all
without the users knowledge and consent. Even Java has this behavior on
Windows (*nix requires a separate package). And you can't scream if you
don't know its being done. There were some noises on forums when this
first came to light, but the average user ether doesn't know or doesn't
care that some other company is forcing their will on how your browser
behaves.

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.

And Mozilla should provide a simple compile switch that can be invoked
to accomplish this (maybe they do already?).

This is accomplished through user permissions. Is the person root? no -
disable menu updates

I don't think this should be relied on. For one thing, if the app is
installed in /usr/local, root perms should not be needed to update it.

And above you said yourself that the *package managers* should be
disabling it... so, again, this should be a packaging/compile flag, so
the admin of the box can decide which updater to use.

I have no insight on Group Policies. A look through their documentation
should give you the answer.

According to the mozilla devs, who are working toward supporting GPO
right now, .msi files are needed, but they can be built using 3rd party
non MS tools...

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

We do use them. I just wish we had people who specialize in this
capability.

Eh? I have never seen an 'updater', incremental or otherwise...
when/where have updaters ever been provided??

If there were 'package specialists', the burden of
distribution/updating could be unloaded from the LibO dev community.

There are - they work for the individual distros, and all LibreOffice
has to do to take advantage of them is simply provide two standard
packages for installation - a full package (could be in the form of a
.tar.gz, or whatever makes sense), and an incremental updater (in the
form of a .diff for *nix, and both full and patch .msi files for windows.

Maybe what is needed is some simple communication to the major distros
to see what form would be best. I cannot imagine this would be that
difficult - they should all be able to work with standard tarballs and
do whatever is needed on their end to make it work.

From all the discussions so far, we have three criteria for Windows
installs:
- clean up after itself
- update (uninstall previous installation)
- Group Policy installs/configuration

Sound about right?

And a wish for an Incremental Update Mechanism similar in nature to what
Mozilla offers.

Yes, sounds about right... the native incremental update would be mainly
for 'home' type users, and the .msi/gpo updates would be for corporate
environments making use of GPO for managing their software.

Also, the use of tar.gz, tar.bz2 or zip should be IMHO reserved for
source file distribution.

Okay... but for a package as large as LibreOffice, it seems to me that a
.diff approach would be much better... the only time it wouldn't be
practical is for major updates (ie, going from 2.0.1 to 3.3)... but code
the update routine to check for that and just download the new version,
uninstall the old version and install the new version.

And as I mentioned earlier, we should look at engaging 'package
specialists' - people who can alleviate some of the burden from devs
about distribution.

Am I missing anything from the discussions?

No, that covers it. I wish I were a programmer so I could help with the
heavy lifting, but I'm not...

-- 

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/

Context


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.