On 07/10/10 11:04 AM, Per Eriksson wrote:
Hi,
If we would implement this for Windows i think it would be a great
win, specially since most users are downloading and using the Windows
version of the software. Then, maybe completing the functionality with
distro-specific solutions leveraging different technologies etc?
I am not sure if Mozilla offer out-of-the-box updating for Firefox on
Linux?
Best
Per
Charles Marcus skrev 2010-10-07 15:32:
On 2010-10-07 9:15 AM, Charles Marcus wrote:
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?).
Again, I have to go back to my earlier posts - Mozilla is not the
shinning example.
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, 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.
On 07/10/10 07:32 AM, Charles Marcus wrote:
On 2010-10-07 9:15 AM, Charles Marcus wrote:
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 accomplished through user permissions. Is the person root? no -
disable menu updates
On 07/10/10 07:15 AM, Charles Marcus wrote:
One caveat though - .msi installers are required (I think) if you want
to incorporate GPO (Group Policies in windows domains) support, and that
is something else that I'd dearly love to see. Can these 3rd party tools
generate .msi files, or at least installers that will work with GPO?
I have no insight on Group Policies. A look through their documentation
should give you the answer.
On 07/10/10 07:15 AM, Charles Marcus wrote:
Fine, so use them... 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. If there were 'package specialists', the burden of
distribution/updating could be unloaded from the LibO dev community.
On 07/10/10 07:15 AM, Charles Marcus wrote:
Windows becomes the corner case...
Fine, let it be the corner case where the internal updater is used.
The mozilla auto-updaters work*great* on Windows, so the LibO
auto-updater should be able to do the same (if coded properly).
> There is no defined standard of where to install files, just
> suggestions. And an update mechanism becomes an external program.
> There are 3rd party apps for updating sources. I believe we should
> explore those options.
I vote for 'whatever works', as long as the efforts will also work
toward full support for GPO...:)
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.
For the *nix environment, I would like to get away from the large bash
shell script file (*.sh).
Also, the use of tar.gz, tar.bz2 or zip should be IMHO reserved for
source file distribution.
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?
Regards,
Scott Furry
--
To unsubscribe, send an empty e-mail to
discuss+unsubscr...@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/
