Automatic Updates

classic Classic list List threaded Threaded
67 messages Options
Next » 1234 « Prev
marcpare4 marcpare4
Reply | Threaded
Open this post in threaded view
|

Re: Automatic Updates

Le 2010-10-06 14:59, Per Eriksson a écrit :

>
> Hi,
>
> Marc Paré skrev 2010-10-06 20:39:
>> Le 2010-10-06 14:30, Steven Shelton a écrit :
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> On 10/6/2010 2:21 PM, Charles Marcus wrote:
>>>> Oh - and one thing that I'd really like to see is a simple 'incremental
>>>> updater' that just downloads a 'patch' file and patches itself, like
>>>> Firefox and Thunderbird and lots of other programs do now
>>>
>> I would vote for this too. It would be amazing if it were capable.
>>
>> Marc
>
> +1
> Tell me how I can help.
>
> Best
> Per

If there were a common method to do incremental updates (linux) to avoid
too much work from the devs, this would be great. Judging by the
discussions, it looks like it could be a challenge though.

Marc

--
To unsubscribe, send an empty e-mail to [hidden email]
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/

todd rme todd rme
Reply | Threaded
Open this post in threaded view
|

Re: Automatic Updates

In reply to this post by Scott Furry
On Wed, Oct 6, 2010 at 7:21 PM, Scott Furry <[hidden email]> wrot
e:

>  On 06/10/10 05:00 PM, Jon Hamkins wrote:
>>
>> On 10/06/2010 11:39 AM, Marc Paré wrote:
>>>
>>>   Le 2010-10-06 14:30, Steven Shelton a écrit :
>>>>
>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>> Hash: SHA1
>>>>
>>>> On 10/6/2010 2:21 PM, Charles Marcus wrote:
>>>>>
>>>>> Oh - and one thing that I'd really like to see is a simple 'increment
al
>>>>> updater' that just downloads a 'patch' file and patches itself, like
>>>>> Firefox and Thunderbird and lots of other programs do now
>>>
>>> I would vote for this too. It would be amazing if it were capable.
>>
>> This functionality is already available in package managers, if we just
>> take care to use it.  yum, for example, supports delta RPMs.  The wa
y

>> this works is LibO would publish delta RPMs that contain all the
>> differences from the previous release, and then the users yum package
>> manager would download the delta RPM, build the full RPM from it, and
>> install.  This approach has been in use for about a year and a half by
>> fedora.  I'm not sure about apt-get systems -- they probably have
>> something similar.  It really saves on bandwidth.
>>
>>      ----Jon
>
> And I agree with Jon. +1
> I've run into situations with OOo where installing/updating an extension
> becomes a mess.
> End result is having to clean out configurations/cache and start from
> scratch. Not Fun :( Not Recommended :P
>
> IIRC, apt-get uses a .diff file mechanism to apply patches.
>
> What I would very much like to avoid is the situation of a repository ful
l
> of 'abandonware'.
> Having vast amounts of choice for extensions is wonderful for the communi
ty,
> so long as these extensions are being actively maintained. This I think i
s
> the problem faced by many community projects where users contribute the
> extension, based on some version of the main program. As the main program
> evolves, the extension suffers 'code rot' and joins a storage device full
 of
> unmaintained/abandoned extensions based on a particular version of the ma
in
> program. (e.g. Apple - app store, Mozilla - add-on, Netbeans, etc.)
>
> Package Management, through dependencies, would ensure that an unsuitable
> extension is not used or installed. The end user can rely on this system
to
> help keep their install stable and secure. Just tweaking a file in a pack
age
> (like being able to edit a Mozilla add-on install.rdf file to pass a basi
c
> revision check) can't be accomplished. The extension contributor needs to
> update the extension, or someone else can pickup maintaining the extensio
n.
>
> To me its a bit of waste where every large development entity has its own
> software repository based on their own update mechanisms. Someone else ha
s
> figured out the hard parts, lets leverage their work rather than reinvent
.
> Let's strive to let the users work on the operating system they've chosen
> and work in a way that is consistent with that OS.
>
> @Roman
> TY. Just trying to keep the conversation lively and informed. :D
>
> Cheers,
> Scott Furry

We already have the opendesktop.org websites like kde-look.org,
gnome-apps.org, and InkscapeStuff.org.  These sites allow for users
uploading and downloading files, support nested categorization, and
have pretty powerful searching.  The sites also implement the Get Hot
New Stuff freedesktop.org API, which is specifically designed for
locating, downloading, and updating content.  Rather than re-inventing
the wheel, it may be good to at least check whether the websites can
be used for hosting the content and Get Hot New Stuff used for
downloading and updating it.

-Todd
--
To unsubscribe, send an empty e-mail to [hidden email]
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/

Charles Marcus Charles Marcus
Reply | Threaded
Open this post in threaded view
|

Re: Automatic Updates

In reply to this post by Jon Hamkins
On 2010-10-06 6:43 PM, Jon Hamkins wrote:
> Then installations and updates can be as simple as
>
> # yum install libreoffice
>
> and
>
> # yum update libreoffice

I like it... :)

--

Best regards,

Charles
--
To unsubscribe, send an empty e-mail to [hidden email]
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/

Charles Marcus Charles Marcus
Reply | Threaded
Open this post in threaded view
|

Re: Automatic Updates

In reply to this post by marcpare4
On 2010-10-06 7:54 PM, Marc Paré wrote:
> If there were a common method to do incremental updates (linux) to
> avoid too much work from the devs, this would be great. Judging by
> the discussions, it looks like it could be a challenge though.

I disagree... the way I see it working is:

1. The devs provide one standard 'diff' file for any/all platforms to
use - it would be up to the individual packagers to take that diff and
apply it according to the standards imposed by their package management
system.

2. The current 'internal' 'updater' (which is more like a notifier and
download manager now) could become a Windows-only true 'Updater' that
applies the diff in the 'Windows way' (just please don't make a system
reboot a requirement)...

--

Best regards,

Charles
--
To unsubscribe, send an empty e-mail to [hidden email]
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/

Charles Marcus Charles Marcus
Reply | Threaded
Open this post in threaded view
|

Re: Automatic Updates

In reply to this post by Jon Hamkins
On 2010-10-06 7:00 PM, Jon Hamkins wrote:
> The way this works is LibO would publish delta RPMs that contain all
> the differences from the previous release, and then the users yum
> package manager would download the delta RPM, build the full RPM from
> it, and install.

Excellent points, and there's the rub. OOo has never (at least to my
knowledge) provided delta updates of any kind.

So the key will be providing this mechanism on the back-end, then just
publish instructions for the different platforms/package managers.

And since Windows is the only one of those platforms that doesn't have a
proper package manager, the current internal 'updater' could become a
Windows-only true 'Updater'.

--

Best regards,

Charles
--
To unsubscribe, send an empty e-mail to [hidden email]
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/

Charles Marcus Charles Marcus
Reply | Threaded
Open this post in threaded view
|

Re: Automatic Updates

In reply to this post by Scott Furry
Hi Scott,

Thanks for the insightful comments...

On 2010-10-06 5:21 PM, Scott Furry wrote:
> a) AFAIK, MSIEXEC doesn't enforce any kind of standards/best
> practices.

I'm not sure I see your point. That doesn't mean that whoever codes the
.msi installer cannot code it to work as I have described. Yes, it means
they will actually have to tell msiexec precisely what to do, but is
that really all that bad of a thing? But ... (see below)

> Sure it does a lovely job of unpacking things and installing, but so do
> a lot of other 3rd party installer programs (NSIS, IzPack, Bitrock, et
> al.).

If it will work better, and more importantly, be easier for the devs to
accomplish the goal of incremental updates, I'm all for it.

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?

> Where these windows-based installers fail is that they do not
> guide or enforce a standard install methodology.

While I agree it would be nice if they did, all that would effectively
mean is less work for the people writing their .msi installers (they
could use internal calls/routines and not worry about where to put
stuff, performing clean-up, etc).

> Case in point is that the install path can be defined to whatever
> your heart desires. Sure you can use a predefined value to fill this
> variable (e.g. %programfiles%, %homedir%, etc), but there is no
> direction in the documentation as to what/where is the correct/best
> place - just suggestions. MSIEXEC is a means to an end - install
> methodology.

All true - but again, I don't see anything that prevents whoever is
writing the .msi to do so successfully and in such a manner as it will
work reliably in all Windows environments.

> Which leads to...
> b) In my original post I mentioned that any install should respect
> the package management of the base operating system. I still agree
> with this notion. And unfortunately, Mozilla breaks this mold. *nix
> users will run into permission issues if they try to update Firefox
> and/or Thunderbird from the program menus. Even Ubuntuzilla (a
> command line python script to perform updates) is external to Mozilla
> and needs permissions to perform an update. I agree an incremental
> update is a good idea, but to emulate these two programs I suggest is
> not the shining example of 'best of bread'.

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. This way
the internal updater would only work for someone who installed from
source, and whether or not it works properly would depend on the one who
installed it installing it in a location where the app has the
appropriate permissions and can successfully update itself.

> The reason I object is that I have run into instances where entities
> external to Mozilla would hijack the install function placing
> plugins into the framework that the user either has no knowledge of
> and/or the installed code can only be removed through extraordinary
> measures (deleting from the command line/file manager). Lovely
> thought, but security becomes a major issue if we go this route.

There must be a certain level of trust where package managers are
concerned. If a packager does something stupid like this, then that
systems users to scream bloody hell. The responsibility of the LibO devs
would end at simply providing the standardized diff.

This would not be an issue for anyone installing the official LibO app,
since the LibO devs would have full control of the process, both install
and updates.

> Package management (i.e. such as apt, yum, rpm, etc) means the
> download is coming from a well defined location (you can trace the
> source) and is put into a specific format (deb, rpm, et al). Security
> is a factor in these methodologies and you can reinstall,
> remove/purge the package through the command line or GUI. Incremental
> updates are apart of this function.

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

> OOo, and post-divergence - LibO, has an internal mechanism for
> updating extensions and itself. But this leads invariably to the
> situation I described above with Mozilla. Security and User
> Permissions then become serious factors. I agree that a better job of
> identifying an existing install and clean up is necessary.
>
> 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... :)

--

Best regards,

Charles
--
To unsubscribe, send an empty e-mail to [hidden email]
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/

Charles Marcus Charles Marcus
Reply | Threaded
Open this post in threaded view
|

Re: Automatic Updates

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

--

Best regards,

Charles
--
To unsubscribe, send an empty e-mail to [hidden email]
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/

Per Eriksson Per Eriksson
Reply | Threaded
Open this post in threaded view
|

Re: Automatic Updates


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

--
To unsubscribe, send an empty e-mail to [hidden email]
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/

vuhung vuhung
Reply | Threaded
Open this post in threaded view
|

Re: Automatic Updates

On Fri, Oct 8, 2010 at 12:04 AM, Per Eriksson <[hidden email]>w
rote:

> I am not sure if Mozilla offer out-of-the-box updating for Firefox on
> Linux?


Yes,

Firefox, ThunderBird has options (which are turned on by default)
that let you choose whether to set them automatically (or manually) update
Firefox/Thunderbird, add-on and search engines.


--
Best Regards,
Nguyen Hung Vu [aka: NVH] ( in Vietnamese: Nguyễn Vũ Hưng
 )
vuhung16plus{remove}@gmail.dot.com
<vuhung16plus%7Bremove%[hidden email]>, YIM: vuhung16 , Skype:
vuhung16plus
A brief profile: http://www.hn.is.uec.ac.jp/~vuhung/Nguyen.Vu.Hung.html

--
To unsubscribe, send an empty e-mail to [hidden email]
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/

vuhung vuhung
Reply | Threaded
Open this post in threaded view
|

Re: Automatic Updates

In reply to this post by Michele Zarri
On Thu, Oct 7, 2010 at 4:27 AM, Michele Zarri <[hidden email]> wrote:

> On 06/10/10 22:21, Jean Hollis Weber wrote:
>
>> On Wed, 2010-10-06 at 14:21 -0400, Charles Marcus wrote:
>>
>>
>>> On 2010-10-06 2:06 PM, Charles Marcus wrote:
>>>
>>>
>>>> Yes there is... use the MSI system, which will take care of things lik
e
>>>> unpacking to the environments /tmp directory, launching the installer
>>>> after unpacking (like it does now), then - and here is the trickey par
t
>>>> I guess - detect a current installation, and offer to upgrade it, or t
o

>>>> install a parallel version.
>>>>
>>>>
>>> Oh - and one thing that I'd really like to see is a simple 'incremental
>>> updater' that just downloads a 'patch' file and patches itself, like
>>> Firefox and Thunderbird and lots of other programs do now.
>>>
>>>
>> +10
>>
>> --Jean
>>
>>
>>
>>
> +1
>
> +1.

And for Mac OS X, as it doesn't (?) have a package management system,
we can leave the update agent as it is.



--
Best Regards,
Nguyen Hung Vu [aka: NVH] ( in Vietnamese: Nguyễn Vũ Hưng
 )
vuhung16plus{remove}@gmail.dot.com
<vuhung16plus%7Bremove%[hidden email]>, YIM: vuhung16 , Skype:
vuhung16plus
A brief profile: http://www.hn.is.uec.ac.jp/~vuhung/Nguyen.Vu.Hung.html

--
To unsubscribe, send an empty e-mail to [hidden email]
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/

Scott Furry Scott Furry
Reply | Threaded
Open this post in threaded view
|

Re: Automatic Updates

In reply to this post by Per Eriksson
  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 [hidden email]
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/

Friedrich Strohmaier Friedrich Strohmaier
Reply | Threaded
Open this post in threaded view
|

Re: Automatic Updates

In reply to this post by Per Eriksson
Hi Per, *,

Per Eriksson schrieb:

[..]

>I am not sure if Mozilla offer out-of-the-box updating for Firefox on
> Linux?


You have to fetch the linux file from Mozilla and unpack it in a folder
where you have write permissions. Call it, use it, update it, - be happy
:o))

Gruß/regards
--
Friedrich

Ansprechpartner / contact person for the "PrOOo-Box"
german language "best Office Suite ever" and more on CD/DVD
http://prooo-box.org  -- footer changed on 2010-10-07


--
To unsubscribe, send an empty e-mail to [hidden email]
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/

Per Eriksson Per Eriksson
Reply | Threaded
Open this post in threaded view
|

Re: Automatic Updates


  Hi,

Do we have skilled people here who are interested in beginning with this
effort, and maybe start planning for this feature?

I've always been interested in pushing things like this forward ;-)

Best

Per

Friedrich Strohmaier skrev 2010-10-07 21:29:

> Hi Per, *,
>
> Per Eriksson schrieb:
>
> [..]
>
>> I am not sure if Mozilla offer out-of-the-box updating for Firefox on
>> Linux?
>
> You have to fetch the linux file from Mozilla and unpack it in a folder
> where you have write permissions. Call it, use it, update it, - be happy
> :o))
>
> Gruß/regards

--
To unsubscribe, send an empty e-mail to [hidden email]
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/

vpanter vpanter
Reply | Threaded
Open this post in threaded view
|

Re: Automatic Updates

In reply to this post by Per Eriksson
  Op 6/10/2010 20:59, Per Eriksson schreef:

>
>  Hi,
>
> Marc Paré skrev 2010-10-06 20:39:
>>  Le 2010-10-06 14:30, Steven Shelton a écrit :
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> On 10/6/2010 2:21 PM, Charles Marcus wrote:
>>>> Oh - and one thing that I'd really like to see is a simple
>>>> 'incremental
>>>> updater' that just downloads a 'patch' file and patches itself, like
>>>> Firefox and Thunderbird and lots of other programs do now
>>>
>> I would vote for this too. It would be amazing if it were capable.
>>
>> Marc
>
> +1
> Tell me how I can help.
>
> Best
> Per
+1

Leo
--
To unsubscribe, send an empty e-mail to [hidden email]
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/

drewjensen drewjensen
Reply | Threaded
Open this post in threaded view
|

Re: Automatic Updates

In reply to this post by Per Eriksson
On Thu, 2010-10-07 at 21:32 +0200, Per Eriksson wrote:

> Hi,
>
> Do we have skilled people here who are interested in beginning with this
> effort, and maybe start planning for this feature?
>
> I've always been interested in pushing things like this forward ;-)
>
> Best
>
> Per

Hi Per,

I've some interest in this - I've subscribed to the dev list however,
which is where I going to bring up an idea - seemed to make more sense
as the correct list.

Thanks

Drew

--
To unsubscribe, send an empty e-mail to [hidden email]
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/

Document Foundation Mail Archives
Earl Melton Earl Melton
Reply | Threaded
Open this post in threaded view
|

Unsubscribe link broken

In reply to this post by Friedrich Strohmaier
The first try bounced back and that was when I noticed that the link at the
bottom of each e-mail is only "hot" past the plus sign following the word
discuss. I then highlighted and copy/pasted the full link into the second try.
Somebody may want to check this out.

 
--
Have a blessed day!
 <>< Earl
--

--
To unsubscribe, send an empty e-mail to [hidden email]
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/

Jean Weber Jean Weber
Reply | Threaded
Open this post in threaded view
|

Re: Unsubscribe link broken

On Thu, 2010-10-07 at 12:56 -0700, Earl Melton wrote:
> The first try bounced back and that was when I noticed that the link at the
> bottom of each e-mail is only "hot" past the plus sign following the word
> discuss. I then highlighted and copy/pasted the full link into the second try.
> Somebody may want to check this out.

That link is "hot" for the whole link in gmail online and in Evolution
on Ubuntu 10.04. What email client are you using?

--Jean


--
To unsubscribe, send an empty e-mail to [hidden email]
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/

Charles Marcus Charles Marcus
Reply | Threaded
Open this post in threaded view
|

Re: Unsubscribe link broken

In reply to this post by Earl Melton
On 2010-10-07 3:56 PM, Earl Melton wrote:
> The first try bounced back and that was when I noticed that the link at the
> bottom of each e-mail is only "hot" past the plus sign following the word
> discuss. I then highlighted and copy/pasted the full link into the second try.
> Somebody may want to check this out.

I just unsubbed and resubbed with no problems using the links...

Methinks your client is busted...

--

Best regards,

Charles
--
To unsubscribe, send an empty e-mail to [hidden email]
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/

Charles Marcus Charles Marcus
Reply | Threaded
Open this post in threaded view
|

Re: Automatic Updates

In reply to this post by Scott Furry
Quote attributions got messed up - sorry...

> Again, I have to go back to my earlier posts - Mozilla is not the
> shinning example.

Their incremental updater works very well on Windows - and with the
Update Notifier extension, all updates can be made pretty much silent
and automatic.

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

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

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

I don't think this should be relied on. For one thing, if the app is
installed in /usr/local, root perms should not be needed to update it.

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.

> I have no insight on Group Policies. A look through their documentation
> should give you the answer.

According to the mozilla devs, who are working toward supporting GPO
right now, .msi files are needed, but they can be built using 3rd party
non MS tools...

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

Eh? I have never seen an 'updater', incremental or otherwise...
when/where have updaters ever been provided??

> If there were 'package specialists', the burden of
> distribution/updating could be unloaded from the LibO dev community.

There are - they work for the individual distros, and all LibreOffice
has to do to take advantage of them is simply provide two standard
packages for installation - a full package (could be in the form of a
.tar.gz, or whatever makes sense), and an incremental updater (in the
form of a .diff for *nix, and both full and patch .msi files for windows.

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.

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

Yes, sounds about right... the native incremental update would be mainly
for 'home' type users, and the .msi/gpo updates would be for corporate
environments making use of GPO for managing their software.

> Also, the use of tar.gz, tar.bz2 or zip should be IMHO reserved for
> source file 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.

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

No, that covers it. I wish I were a programmer so I could help with the
heavy lifting, but I'm not...

--

Best regards,

Charles
--
To unsubscribe, send an empty e-mail to [hidden email]
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/

Goran Rakic Goran Rakic
Reply | Threaded
Open this post in threaded view
|

Re: Unsubscribe link broken

In reply to this post by Charles Marcus
У чет, 07. 10 2010. у 16:45 -0400, Charles Marcus пише:

> I just unsubbed and resubbed with no problems using the links...
>
> Methinks your client is busted...

As this can confuse other people, and we should try to make unsubscribe
for people as easy as possible to avoid angry emails, can we just drop
some words to make it fit in a single line:

To unsubscribe, e-mail to [hidden email]
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/

Best regards,
Goran Rakic
 

--
To unsubscribe, send an empty e-mail to [hidden email]
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/

Next » 1234 « Prev