Re: [tdf-discuss] Automatic Updates

 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
> > *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 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) - 
http://support.mozilla.com/en-US/kb/activex
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
> > > 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.
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?

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/