Re: [tdf-discuss] Automatic Updates

On 2010-10-07 6:05 PM, Scott Furry wrote:
>  On 07/10/10 03:04 PM, Charles Marcus wrote:
> > 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.

Why not? If the software is installed somewhere that does not require
root permissions, why would root perms be needed to update it? Makes no
sense. *nix is perfectly capable of allowing normal users to install
software.

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

> Yes, its disused and out of favor, but WinXP users would still see the
> plugin installed.

No, they wouldn't (in the case of ActiveX) - since apparently you missed
my point that there is no ActiveX for Firefox - never has been, never
will be (unless someone pony's up a bunch of cash).

> 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 one (ActiveX) has nothing to do with the other
(Microsoft silently installing .net extensions)...

> This is a problem. Why should package managers dig into the code to
> disable something?

?? They don't have to 'dig into the code' to flip compile switches for
specific packages - they do that all the time (some packages are built
with SSL support, some aren't, etc).

> And on *nix, root(or superuser) is required. You are either root or
> on the "sudoer" list. Can't get away from that.

My understanding is this is only true if you're installing something for
everyone. If you're installing something only for yourself - ie, like I
said earlier, in /usr/local, or even in /home/user/apps - then I am
fairly certain that root is *not* required...

Am I wrong?

> > On many computer operating systems, the *superuser*, or *root*, is
> > a special user account used for system administration.

<sigh> I know what root is.

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

My bad - I forgot I had replied to myself... apologies...

> Sounds like GPO (or enterprise installs) should be looked as a
> separate usability case once the dust settles here.

No doubt...

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

I was speaking to an updater for Windows... there never has been one.

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

I do not think that LibO should be in the business of providing
individual distro packages - let the distro package managers do that. It
will free up lots of developer resources to focus on programming, not
building/providing packages.

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

<sigh> so compress it.

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

Yes, and the deb package maintainers generally pull *the source* from
the source provider (in this case, the LibO repositories), then builds
their packages.

Again - let the distro package maintainers do the heavy lifting there...
all LibO needs to do is provide access to the source.

Maybe one problem in our communication here is you seem to be focused on
the historical process of the OOo community has always provided all of
these different packages. How about we make building LibO easier,
provide access to the source, and let the package maintainers take it
from there?

-- 

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/