Re: [tdf-discuss] Automatic Updates

 On 07/10/10 03:04 PM, Charles Marcus wrote:
> > 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.
True enough. But this feature is not available to non-root users on *nix.
> > 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.
Not a typo. Not everyone has coughed up to get the latest/greatest 
according to Redmond.
Yes, its disused and out of favor, but WinXP users would still see the 
plugin installed.

Again, I dislike the idea of silently dumping some "feature" into a 
program path because they "think" they know better. The user should have 
control over their install. (Enterprise installs open a very different 
use case).

> > > > 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 a problem. Why should package managers dig into the code to 
disable something?
> > 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 on *nix, root(or superuser) is required. You are either root or on 
the "sudoer" list.
Can't get away from that.
> On many computer operating systems, the *superuser*, or *root*, is a 
> special user account used for system administration.
>
> Separation of administrative privileges from normal user privileges 
> makes an operating system more resistant to viruses and other malware. 
> Additionally, in organizations, administrative privileges are often 
> reserved for authorized individuals in order to control abuse, misuse, 
> or other undesired activities by end-users.
http://en.wikipedia.org/wiki/Root_user

> 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.
That's your quote, not mine. I agree that the functionality should be 
disabled, but package management involves strictly 'packaging' for a 
distribution. This may involve compiling the code. And as you suggested 
a compile switch could be used.
> > 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...
Sounds like GPO (or enterprise installs) should be looked as a separate 
usability case once the dust settles here.
> > > 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??
That's the purpose of package management programs (apt, dpkg, yum, rpm, 
etc.).

> What is Apt? Apt /(for *A*dvanced *P*ackage *T*ool)/ is a set of core 
> tools inside Debian. Apt makes it possible to:
>
>     * Install applications
>     * Remove applications
>     * Keep your applications up to date
>     * And much more... 
Quoted from http://wiki.debian.org/Apt
Just one example of many in the *nix world.

> > 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.
Not all of them. Case in point is the person who put together the Debian 
packages (Nikola Yanev - great work BTW :D ). There are others out there 
in the community. It would be great if they (and their skills) could be 
be brought together allowing for a one-stop-download location of 
packages for the different OS distributions.

This would then be considered the "upstream repository" from which the 
various OS distribution teams could then mirror/pull down LibO for 
distribution to users of that OS.
> >  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.
Again...a package is supplied in a compressed archive format, albeit 
with a different extension.
> Debian packages are standard Unix ar archives that include two 
> gzipped, bzipped or lzmaed tar archives: one that holds the control 
> information and another that contains the data.
http://en.wikipedia.org/wiki/Deb_(file_format)
> > 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...
+1
You and me both.
Know just enough to be dangerous, but not enough to be helpful. :D

Regards,
Scott Furry

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