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

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

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

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

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,

To unsubscribe, send an empty e-mail to
All messages you send to this list will be publicly archived and cannot be deleted.
List archives are available at


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.