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

 On 07/10/10 05:00 PM, Charles Marcus wrote:
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 a local user only in there own directory, ok.
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).
I have seen an ActiveX plugin installed in Firefox (which I promptly removed).
A quick google search shows that:
a) Mozilla doesn't support it (no surprise) - b) there are others who have created add-ins/plugins for firefox (why is beyond me)
...but the one (ActiveX) has nothing to do with the other
(Microsoft silently installing .net extensions)...
Agree to disagree...

But we are agreed that its bad to silently push plugins/software/extensions/<insert name> onto an application without the user knowing what to expect. Regardless of the examples...its just bad. Right?
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).
Agreed. Your previous text led me to believe you were suggesting that the person doing the packaging was to edit the source code. This person doesn't have a need to open up and/or change source code.
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?
No. Your not wrong. But installing locally is usually done either for development purposes or some other very-special need. Package installations do not install for "local use only" as that is not the recommend methodology.
My bad - I forgot I had replied to myself... apologies...
No worries. :)

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

No doubt...
I sense a "task force" would be useful to resolve this issue (not as grand as the IETF mind you). Just a few select people to document the use cases, identify risks/roadblocks, detail requirements...usual project management.
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.
What about Windows Update?
From a non-os software side, I do recall seeing a update/notify program. Can't remember the name and I no longer can find the link.
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.
The Debian distribution has over 25,000 different packages in their repository.
You think Debian has the time to look after this stuff?
Especially since its staffed with volunteers around the globe?

If somebody from the organization and/or community does not do the work (or DF pays someone to do it) LibO will either *never make into the repositories* -or- *become an extremely low priority* for 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.
<sigh>  so compress it.
That's what the workflow of creating a deb/rpm/et al does.
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.
This is why I suggestion packaging specialists. See my comments about Debian above.
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?
DF already provides access to the source, as well as instructions on how to build the source, both available from the DF home page. I suspect that my strict-*nix focus and trying to communicate non-windows may also be an issue.

Its not about historical (at least I don't think it is) perspective. IMHO, its about how the *nix community at large functions, which can cause someone not versed in it to become exasperated. Somewhere in my bookmarks is a link to "the cathedral and the bazaar", a book that discusses differences between commercial and open-source development. Would that be of interest to you?

Scott Furry

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.