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+unsubscr...@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/
