Automatic Updates

classic Classic list List threaded Threaded
67 messages Options
Next » 1234
Paul A Norman Paul A Norman
Reply | Threaded
Open this post in threaded view
|

Automatic Updates

Not sure where thinking is on this for LiBO at the moment, but is it
concievable that updating even to each new version could, after a User
response, be automatic and if elected by the User - replace the
previous version automatically please?

Paul
--
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: Automatic Updates

У сре, 06. 10 2010. у 13:22 +1300, Paul A Norman пише:
> Not sure where thinking is on this for LiBO at the moment, but is it
> concievable that updating even to each new version could, after a User
> response, be automatic and if elected by the User - replace the
> previous version automatically please?
>
> Paul

Hi Paul,

A first step would be to replicate the update notification feature
available in the OpenOffice.org. I guess only infrastructure is missing
for that one.

I remember last year in Orvieto there were some talks about new
packaging for all platforms that would allow online installation
(allowing user to select, download and install any combination of
languages, cutting space requirements to do full install sets).

I do not know what is the current status of this development and if it
would be easier to add autoupdate feature after that task is completed.

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

Paul A Norman Paul A Norman
Reply | Threaded
Open this post in threaded view
|

Re: Automatic Updates

What I have found is that under OOO I have always been left with
install directories with Mbs of space used for previous installations,
the uninstall or new install doesn't seem to have removed them.

I have been thinking tha it would be neat to have as it were, one
install of LiBO and have it "updated" in all the same directories all
the time, even if it were a new version of LiBO that was being
"installed - updated", unless the User specifically elected to have
multiple installations of different versions, making the default that
there is only ever one main copy that is updated all the time.

Paul

On 6 October 2010 13:35, Goran Rakic <[hidden email]> wrote:
> У сре, 06. 10 2010. у 13:22 +1300, Paul A Norman
 пише:

>> Not sure where thinking is on this for LiBO at the moment, but is it
>> concievable that updating even to each new version could, after a User
>> response, be automatic and if elected by the User - replace the
>> previous version automatically please?
>>
>> Paul
>
> Hi Paul,
>
> A first step would be to replicate the update notification feature
> available in the OpenOffice.org. I guess only infrastructure is missing
> for that one.
>
> I remember last year in Orvieto there were some talks about new
> packaging for all platforms that would allow online installation
> (allowing user to select, download and install any combination of
> languages, cutting space requirements to do full install sets).
>
> I do not know what is the current status of this development and if it
> would be easier to add autoupdate feature after that task is completed.
>
> Kind regards,
> Goran Rakic
>
>
> --
> To unsubscribe, send an empty e-mail to discuss+unsubscribe@documentfound
ation.org
> All messages you send to this list will be publicly archived and cannot b
e deleted.
> List archives are available at http://www.documentfoundation.org/lists/di
scuss/
>
>
--
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

  On 05/10/10 07:36 PM, Paul A Norman wrote:

> What I have found is that under OOO I have always been left with
> install directories with Mbs of space used for previous installations,
> the uninstall or new install doesn't seem to have removed them.
>
> I have been thinking tha it would be neat to have as it were, one
> install of LiBO and have it "updated" in all the same directories all
> the time, even if it were a new version of LiBO that was being
> "installed - updated", unless the User specifically elected to have
> multiple installations of different versions, making the default that
> there is only ever one main copy that is updated all the time.
>
> Paul
>
> On 6 October 2010 13:35, Goran Rakic<[hidden email]>  wrote:
>> У сре, 06. 10 2010. у 13:22 +1300, Paul A Norman
>   пише:
>>> Not sure where thinking is on this for LiBO at the moment, but is it
>>> concievable that updating even to each new version could, after a User
>>> response, be automatic and if elected by the User - replace the
>>> previous version automatically please?
>>>
>>> Paul
>> Hi Paul,
>>
>> A first step would be to replicate the update notification feature
>> available in the OpenOffice.org. I guess only infrastructure is missing
>> for that one.
>>
>> I remember last year in Orvieto there were some talks about new
>> packaging for all platforms that would allow online installation
>> (allowing user to select, download and install any combination of
>> languages, cutting space requirements to do full install sets).
>>
>> I do not know what is the current status of this development and if it
>> would be easier to add autoupdate feature after that task is completed.
>>
>> Kind 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/
Paul,
I do agree with the principles of your suggestion. Certainly on Windows
installs this is true as evidenced by the "Install Folder" left on the
desktop. And leaving the install folders around, not cleaning up after
the install, or an uninstall not removing everything that was installed
seems rather unprofessional. So, yes, I concur. However, I believe that
may be only for Windows...

*nix(Linux|Unix) installs can use a variety of install/package
management programs (e.g. apt, yum, rpm, et al.) that resolve this
issue. And these package management programs can also purge
configuration files when removing a package. Package management also
handle the kind of automatic update functionality you mention. But this
is for *nix only...

Any installation method that is deployed, in my mind, must 'respect' the
package management of the base operating system. I get rather annoyed
with multiple types of update/install mechanisms (setup.py for certain
python based apps for example) that seem to circumvent OS package
management programs. But there is no 'one size fits all' solution. There
are numerous install frameworks (e.g. NSIS - NullSoft Install Script[Win
only], or IzPack[Java - used by scala]). Again, they seem to circumvent
package management on *nix machines while catering to Windows based
installs.

Problem is that Windows doesn't have a package management system. There
is no one simple way to install, update or uninstall. Yes, there is
msiexec, but that just provides a means to an end and doesn't handle
update mechanisms nor framework/standardize installs. As for update
mechanisms, we're left with 3rd party programs.

Other than making sure that LibO cleans up after itself, how much effort
do we want to put into installers?

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/

Paul A Norman Paul A Norman
Reply | Threaded
Open this post in threaded view
|

Re: Automatic Updates

Nice clear thinking thanks Scott.

I have heard from people that they don't like these artifacts of
install, and also they often don't realise that they need to uninstall
a previous version of OOO - and you can use quite a bit of disk space
up, you end up with an install set and and install for each version of
OOO at present afaik.

The non-real package manager situation on Windows was I believe a
business decission of M$ early in the piece focussed around commercial
matters and policy ratrher than the User experience and good OS
management.  The Control Panel Add/Remove feature to my knowledge
presents little or no behind the scenes core management tools for
developers in the light of what you are talking about.

Maybe an auto detect determined - LiBO package management routine for
M$ systems, auto-detect  as OOO presrntly does for other OS specific
needs/features?

I reckon that LiBO could give a really good lead in this - M$ also
often leaves messes behind including large un-needed install and
update files under WIndows DIR TREE - maybe this could be  a point of
differecne for LiBo amongst  Office Products on M$ at least?

Better management of these files could be a real draw card for people
on M$, and there are still an awful lot of those M$ OS potential LiBO
people!

Paul

On 6 October 2010 18:04, Scott Furry <[hidden email]> wrote:

>  On 05/10/10 07:36 PM, Paul A Norman wrote:
>>
>> What I have found is that under OOO I have always been left with
>> install directories with Mbs of space used for previous installations,
>> the uninstall or new install doesn't seem to have removed them.
>>
>> I have been thinking tha it would be neat to have as it were, one
>> install of LiBO and have it "updated" in all the same directories all
>> the time, even if it were a new version of LiBO that was being
>> "installed - updated", unless the User specifically elected to have
>> multiple installations of different versions, making the default that
>> there is only ever one main copy that is updated all the time.
>>
>> Paul
>>
>> On 6 October 2010 13:35, Goran Rakic<[hidden email]>  wrote:
>>>
>>> У сре, 06. 10 2010. у 13:22 +1300, Paul A Norm
an

>>
>>  пише:
>>>>
>>>> Not sure where thinking is on this for LiBO at the moment, but is it
>>>> concievable that updating even to each new version could, after a User
>>>> response, be automatic and if elected by the User - replace the
>>>> previous version automatically please?
>>>>
>>>> Paul
>>>
>>> Hi Paul,
>>>
>>> A first step would be to replicate the update notification feature
>>> available in the OpenOffice.org. I guess only infrastructure is missing
>>> for that one.
>>>
>>> I remember last year in Orvieto there were some talks about new
>>> packaging for all platforms that would allow online installation
>>> (allowing user to select, download and install any combination of
>>> languages, cutting space requirements to do full install sets).
>>>
>>> I do not know what is the current status of this development and if it
>>> would be easier to add autoupdate feature after that task is completed.
>>>
>>> Kind 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/
>
> Paul,
> I do agree with the principles of your suggestion. Certainly on Windows
> installs this is true as evidenced by the "Install Folder" left on the
> desktop. And leaving the install folders around, not cleaning up after th
e
> install, or an uninstall not removing everything that was installed seems
> rather unprofessional. So, yes, I concur. However, I believe that may be
> only for Windows...
>
> *nix(Linux|Unix) installs can use a variety of install/package management
> programs (e.g. apt, yum, rpm, et al.) that resolve this issue. And these
> package management programs can also purge configuration files when remov
ing
> a package. Package management also handle the kind of automatic update
> functionality you mention. But this is for *nix only...
>
> Any installation method that is deployed, in my mind, must 'respect' the
> package management of the base operating system. I get rather annoyed wit
h
> multiple types of update/install mechanisms (setup.py for certain python
> based apps for example) that seem to circumvent OS package management
> programs. But there is no 'one size fits all' solution. There are numerou
s
> install frameworks (e.g. NSIS - NullSoft Install Script[Win only], or
> IzPack[Java - used by scala]). Again, they seem to circumvent package
> management on *nix machines while catering to Windows based installs.
>
> Problem is that Windows doesn't have a package management system. There i
s
> no one simple way to install, update or uninstall. Yes, there is msiexec,
> but that just provides a means to an end and doesn't handle update
> mechanisms nor framework/standardize installs. As for update mechanisms,
> we're left with 3rd party programs.
>
> Other than making sure that LibO cleans up after itself, how much effort
do
> we want to put into installers?
>
> 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 b
e
> deleted.
> List archives are available at
> http://www.documentfoundation.org/lists/discuss/
>
>
--
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

  And I wholeheartedly agree with the notion that M$ missed the boat here.
Also, some kind of 'package management' feature would be nice.
Note that Windows is only one OS (albeit with a rather large user base)
out of many that can run LibO.

The garbage that gets left behind after typical application
install/uninstall on Windows both in the registry or dll files is in my
mind a security flaw in its own right. There is a little known tool from
M$ Download Centre called Windows Installer Cleanup that does some
searching for registry and file/folder remnants.

However, as for LibO, I concur that we should lead by example. For
example, Debian publishes deb package guidelines and we should encourage
devs to follow these guidelines as best as possible (and we probably do
already, but state it anyway). And in some cases, these 'guidelines' can
sometimes be more like hard&fast rules to live by.

Conversely, there are 'guidelines'/'best practices' for Windows that
leave one the impression that "they're not rules. They're more like
guidelines." (POTC-TBP). In the end, the devs (guided by the community)
have to define those 'best practices'. And cleaning up after an install
is a good place to start. After that? That depends on feedback.

Again, we're left with a plethora of 3rd party tools to choose from (if
this choice isn't set in stone already) to handle
install/update/uninstall functions. If there is an update functionality
available (and AFAIK there is - tiger something springs to mind), let's
use that rather than expecting devs to delve into MS OS
fundamentals/package system. I don't think WE(community inclusive
variety of the word) have the kind of bandwidth to develop a one-off
windows based package system. That subject alone would probably open up
barrels (to heck with cans) of worms.

Food for thought.
Regards,
Scott Furry

On 06/10/10 12:11 AM, Paul A Norman wrote:

> Nice clear thinking thanks Scott.
>
> I have heard from people that they don't like these artifacts of
> install, and also they often don't realise that they need to uninstall
> a previous version of OOO - and you can use quite a bit of disk space
> up, you end up with an install set and and install for each version of
> OOO at present afaik.
>
> The non-real package manager situation on Windows was I believe a
> business decission of M$ early in the piece focussed around commercial
> matters and policy ratrher than the User experience and good OS
> management.  The Control Panel Add/Remove feature to my knowledge
> presents little or no behind the scenes core management tools for
> developers in the light of what you are talking about.
>
> Maybe an auto detect determined - LiBO package management routine for
> M$ systems, auto-detect  as OOO presrntly does for other OS specific
> needs/features?
>
> I reckon that LiBO could give a really good lead in this - M$ also
> often leaves messes behind including large un-needed install and
> update files under WIndows DIR TREE - maybe this could be  a point of
> differecne for LiBo amongst  Office Products on M$ at least?
>
> Better management of these files could be a real draw card for people
> on M$, and there are still an awful lot of those M$ OS potential LiBO
> people!
>
> Paul
>
> On 6 October 2010 18:04, Scott Furry<[hidden email]>  wrote:
>>   On 05/10/10 07:36 PM, Paul A Norman wrote:
>>> What I have found is that under OOO I have always been left with
>>> install directories with Mbs of space used for previous installations,
>>> the uninstall or new install doesn't seem to have removed them.
>>>
>>> I have been thinking tha it would be neat to have as it were, one
>>> install of LiBO and have it "updated" in all the same directories all
>>> the time, even if it were a new version of LiBO that was being
>>> "installed - updated", unless the User specifically elected to have
>>> multiple installations of different versions, making the default that
>>> there is only ever one main copy that is updated all the time.
>>>
>>> Paul
>>>
>>> On 6 October 2010 13:35, Goran Rakic<[hidden email]>    wrote:
>>>> У сре, 06. 10 2010. у 13:22 +1300, Paul A Norm
> an
>>>   пише:
>>>>> Not sure where thinking is on this for LiBO at the moment, but is it
>>>>> concievable that updating even to each new version could, after a User
>>>>> response, be automatic and if elected by the User - replace the
>>>>> previous version automatically please?
>>>>>
>>>>> Paul
>>>> Hi Paul,
>>>>
>>>> A first step would be to replicate the update notification feature
>>>> available in the OpenOffice.org. I guess only infrastructure is missing
>>>> for that one.
>>>>
>>>> I remember last year in Orvieto there were some talks about new
>>>> packaging for all platforms that would allow online installation
>>>> (allowing user to select, download and install any combination of
>>>> languages, cutting space requirements to do full install sets).
>>>>
>>>> I do not know what is the current status of this development and if it
>>>> would be easier to add autoupdate feature after that task is completed.
>>>>
>>>> Kind 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/
>> Paul,
>> I do agree with the principles of your suggestion. Certainly on Windows
>> installs this is true as evidenced by the "Install Folder" left on the
>> desktop. And leaving the install folders around, not cleaning up after th
> e
>> install, or an uninstall not removing everything that was installed seems
>> rather unprofessional. So, yes, I concur. However, I believe that may be
>> only for Windows...
>>
>> *nix(Linux|Unix) installs can use a variety of install/package management
>> programs (e.g. apt, yum, rpm, et al.) that resolve this issue. And these
>> package management programs can also purge configuration files when remov
> ing
>> a package. Package management also handle the kind of automatic update
>> functionality you mention. But this is for *nix only...
>>
>> Any installation method that is deployed, in my mind, must 'respect' the
>> package management of the base operating system. I get rather annoyed wit
> h
>> multiple types of update/install mechanisms (setup.py for certain python
>> based apps for example) that seem to circumvent OS package management
>> programs. But there is no 'one size fits all' solution. There are numerou
> s
>> install frameworks (e.g. NSIS - NullSoft Install Script[Win only], or
>> IzPack[Java - used by scala]). Again, they seem to circumvent package
>> management on *nix machines while catering to Windows based installs.
>>
>> Problem is that Windows doesn't have a package management system. There i
> s
>> no one simple way to install, update or uninstall. Yes, there is msiexec,
>> but that just provides a means to an end and doesn't handle update
>> mechanisms nor framework/standardize installs. As for update mechanisms,
>> we're left with 3rd party programs.
>>
>> Other than making sure that LibO cleans up after itself, how much effort
> do
>> we want to put into installers?
>>
>> 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 b
> e
>> deleted.
>> List archives are available at
>> http://www.documentfoundation.org/lists/discuss/
--
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/

Paul A Norman Paul A Norman
Reply | Threaded
Open this post in threaded view
|

Re: Automatic Updates

"If there is an update functionality available (and AFAIK there is -
tiger something springs to mind), let's use that rather than expecting
devs to delve into MS OS fundamentals/package system."

Intutively that seems really does seem by far the best approach.

Paul

On 6 October 2010 19:36, Scott Furry <[hidden email]> wrote:
>  And I wholeheartedly agree with the notion that M$ missed the boat
here.
> Also, some kind of 'package management' feature would be nice.
> Note that Windows is only one OS (albeit with a rather large user base) o
ut
> of many that can run LibO.
>
> The garbage that gets left behind after typical application
> install/uninstall on Windows both in the registry or dll files is in my m
ind
> a security flaw in its own right. There is a little known tool from M$
> Download Centre called Windows Installer Cleanup that does some searching
> for registry and file/folder remnants.
>
> However, as for LibO, I concur that we should lead by example. For exampl
e,
> Debian publishes deb package guidelines and we should encourage devs to
> follow these guidelines as best as possible (and we probably do already,
but
> state it anyway). And in some cases, these 'guidelines' can sometimes be
> more like hard&fast rules to live by.
>
> Conversely, there are 'guidelines'/'best practices' for Windows that leav
e
> one the impression that "they're not rules. They're more like guidelines.
"
> (POTC-TBP). In the end, the devs (guided by the community) have to define
> those 'best practices'. And cleaning up after an install is a good place
to
> start. After that? That depends on feedback.
>
> Again, we're left with a plethora of 3rd party tools to choose from (if t
his
> choice isn't set in stone already) to handle install/update/uninstall
> functions. If there is an update functionality available (and AFAIK there
 is

> - tiger something springs to mind), let's use that rather than expecting
> devs to delve into MS OS fundamentals/package system. I don't think
> WE(community inclusive variety of the word) have the kind of bandwidth to
> develop a one-off windows based package system. That subject alone would
> probably open up barrels (to heck with cans) of worms.
>
> Food for thought.
> Regards,
> Scott Furry
>
> On 06/10/10 12:11 AM, Paul A Norman wrote:
>>
>> Nice clear thinking thanks Scott.
>>
>> I have heard from people that they don't like these artifacts of
>> install, and also they often don't realise that they need to uninstall
>> a previous version of OOO - and you can use quite a bit of disk space
>> up, you end up with an install set and and install for each version of
>> OOO at present afaik.
>>
>> The non-real package manager situation on Windows was I believe a
>> business decission of M$ early in the piece focussed around commercial
>> matters and policy ratrher than the User experience and good OS
>> management.  The Control Panel Add/Remove feature to my knowledge
>> presents little or no behind the scenes core management tools for
>> developers in the light of what you are talking about.
>>
>> Maybe an auto detect determined - LiBO package management routine for
>> M$ systems, auto-detect  as OOO presrntly does for other OS specifi
c
>> needs/features?
>>
>> I reckon that LiBO could give a really good lead in this - M$ also
>> often leaves messes behind including large un-needed install and
>> update files under WIndows DIR TREE - maybe this could be  a point
of
>> differecne for LiBo amongst  Office Products on M$ at least?
>>
>> Better management of these files could be a real draw card for people
>> on M$, and there are still an awful lot of those M$ OS potential LiBO
>> people!
>>
>> Paul
>>
>> On 6 October 2010 18:04, Scott Furry<[hidden email]>  wro
te:

>>>
>>>  On 05/10/10 07:36 PM, Paul A Norman wrote:
>>>>
>>>> What I have found is that under OOO I have always been left with
>>>> install directories with Mbs of space used for previous installations,
>>>> the uninstall or new install doesn't seem to have removed them.
>>>>
>>>> I have been thinking tha it would be neat to have as it were, one
>>>> install of LiBO and have it "updated" in all the same directories all
>>>> the time, even if it were a new version of LiBO that was being
>>>> "installed - updated", unless the User specifically elected to have
>>>> multiple installations of different versions, making the default that
>>>> there is only ever one main copy that is updated all the time.
>>>>
>>>> Paul
>>>>
>>>> On 6 October 2010 13:35, Goran Rakic<[hidden email]>    
wrote:
>>>>>
>>>>> У сре, 06. 10 2010. у 13:22 +1300, Paul A No
rm
>>
>> an
>>>>
>>>>  пише:
>>>>>>
>>>>>> Not sure where thinking is on this for LiBO at the moment, but is it
>>>>>> concievable that updating even to each new version could, after a Us
er
>>>>>> response, be automatic and if elected by the User - replace the
>>>>>> previous version automatically please?
>>>>>>
>>>>>> Paul
>>>>>
>>>>> Hi Paul,
>>>>>
>>>>> A first step would be to replicate the update notification feature
>>>>> available in the OpenOffice.org. I guess only infrastructure is missi
ng
>>>>> for that one.
>>>>>
>>>>> I remember last year in Orvieto there were some talks about new
>>>>> packaging for all platforms that would allow online installation
>>>>> (allowing user to select, download and install any combination of
>>>>> languages, cutting space requirements to do full install sets).
>>>>>
>>>>> I do not know what is the current status of this development and if i
t
>>>>> would be easier to add autoupdate feature after that task is complete
d.
>>>>>
>>>>> Kind 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 cann
ot
>>>>> be deleted.
>>>>> List archives are available at
>>>>> http://www.documentfoundation.org/lists/discuss/
>>>
>>> Paul,
>>> I do agree with the principles of your suggestion. Certainly on Windows
>>> installs this is true as evidenced by the "Install Folder" left on the
>>> desktop. And leaving the install folders around, not cleaning up after
th
>>
>> e
>>>
>>> install, or an uninstall not removing everything that was installed see
ms
>>> rather unprofessional. So, yes, I concur. However, I believe that may b
e
>>> only for Windows...
>>>
>>> *nix(Linux|Unix) installs can use a variety of install/package manageme
nt
>>> programs (e.g. apt, yum, rpm, et al.) that resolve this issue. And thes
e
>>> package management programs can also purge configuration files when rem
ov
>>
>> ing
>>>
>>> a package. Package management also handle the kind of automatic update
>>> functionality you mention. But this is for *nix only...
>>>
>>> Any installation method that is deployed, in my mind, must 'respect' th
e
>>> package management of the base operating system. I get rather annoyed w
it
>>
>> h
>>>
>>> multiple types of update/install mechanisms (setup.py for certain pytho
n
>>> based apps for example) that seem to circumvent OS package management
>>> programs. But there is no 'one size fits all' solution. There are numer
ou
>>
>> s
>>>
>>> install frameworks (e.g. NSIS - NullSoft Install Script[Win only], or
>>> IzPack[Java - used by scala]). Again, they seem to circumvent package
>>> management on *nix machines while catering to Windows based installs.
>>>
>>> Problem is that Windows doesn't have a package management system. There
 i
>>
>> s
>>>
>>> no one simple way to install, update or uninstall. Yes, there is msiexe
c,
>>> but that just provides a means to an end and doesn't handle update
>>> mechanisms nor framework/standardize installs. As for update mechanisms
,
>>> we're left with 3rd party programs.
>>>
>>> Other than making sure that LibO cleans up after itself, how much effor
t

>>
>> do
>>>
>>> we want to put into installers?
>>>
>>> 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
 b

>>
>> e
>>>
>>> deleted.
>>> List archives are available at
>>> http://www.documentfoundation.org/lists/discuss/
>
> --
> To unsubscribe, send an empty e-mail to
> [hidden email]
> All messages you send to this list will be publicly archived and cannot b
e
> deleted.
> List archives are available at
> http://www.documentfoundation.org/lists/discuss/
>
>
--
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
On 2010-10-06 1:04 AM, Scott Furry wrote:
> Any installation method that is deployed, in my mind, must 'respect'
> the package management of the base operating system.

+1 - So, for most *nix's, this would mean that the built-in LibO updater
should be disabled, and let the systems package manager take care of it.

> Problem is that Windows doesn't have a package management system.
> There is no one simple way to install, update or uninstall.

Yes there is... use the MSI system, which will take care of things like
unpacking to the environments /tmp directory, launching the installer
after unpacking (like it does now), then - and here is the trickey part
I guess - detect a current installation, and offer to upgrade it, or to
install a parallel version.

I am not a programmer, but I know enough about it to know that this
wouldn't be all that difficult to do for a good programmer who has
experience writing installer scripts for the windows platform.

> Yes, there is msiexec, but that just provides a means to an end and
> doesn't handle update mechanisms nor framework/standardize installs.
> As for update mechanisms, we're left with 3rd party programs.

The current OOo auto-update detector would be fine if the update process
itself worked as I described above.

> Other than making sure that LibO cleans up after itself, how much
> effort do we want to put into installers?

Since updates is one of the things that seems to confuse a lot of
people, I think it would be a good thing if this could be fixed...

Oh - and while we're on the subject, please, bring back the ability to
choose how File Associations are configured in the GUI installer - but
with the addition of the new XML versions too (so, there would be 6
checkbox/choices instead of just 3.

--

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-06 2:06 PM, Charles Marcus wrote:
> Yes there is... use the MSI system, which will take care of things like
> unpacking to the environments /tmp directory, launching the installer
> after unpacking (like it does now), then - and here is the trickey part
> I guess - detect a current installation, and offer to upgrade it, or to
> 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.

--

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/

Steven Shelton Steven Shelton
Reply | Threaded
Open this post in threaded view
|

Re: Automatic Updates


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

+1

- --
Steven Shelton
Deputy Undersecretary for Made-up Titles
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
 
iEYEARECAAYFAkyswC4ACgkQO+AD2HqgRoB0tgCgrLE++fnRuftt7I7UewR7xthz
s4QAn26yIA9YQqqoLfyJlRUkmUSVLK03
=BaN+
-----END PGP SIGNATURE-----

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

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

Re: Automatic Updates

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

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

Re: Automatic Updates

In reply to this post by Charles Marcus
Hi,

Am 06.10.2010 20:21, schrieb Charles Marcus:

> On 2010-10-06 2:06 PM, Charles Marcus wrote:
>> Yes there is... use the MSI system, which will take care of things like
>> unpacking to the environments /tmp directory, launching the installer
>> after unpacking (like it does now), then - and here is the trickey part
>> I guess - detect a current installation, and offer to upgrade it, or to
>> 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.

++1

Erich

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

In reply to this post by marcpare4

  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
--
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: Automatic Updates

In reply to this post by Charles Marcus
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 like
> > unpacking to the environments /tmp directory, launching the installer
> > after unpacking (like it does now), then - and here is the trickey part
> > I guess - detect a current installation, and offer to upgrade it, or to
> > 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


--
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 Charles Marcus
  On 06/10/10 12:21 PM, 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 like
>> unpacking to the environments /tmp directory, launching the installer
>> after unpacking (like it does now), then - and here is the trickey part
>> I guess - detect a current installation, and offer to upgrade it, or to
>> 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.
Charles,

For the most part I agree with you. Where, I have a problem is with:
a) what MSIEXEC does
b) purpose/function of incremental updates

a) AFAIK, MSIEXEC doesn't enforce any kind of standards/best practices.
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.). Where these windows-based installers fail is that they do not
guide or enforce a standard install methodology. 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.

Granted, how LibO uses the windows install is put into question. And I
agree, we(community plural) should be doing a better job. I know of
other programs whose installers ask if you want to remove the previous
installation. So it is possible. The capabilities are there to
install/uninstall, but the update mechanism is up for grabs as several
programs each have their own ideas about how to scan the WWW for and
incorporate updates.

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

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.

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.

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

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/

Michele Zarri Michele Zarri
Reply | Threaded
Open this post in threaded view
|

Re: Automatic Updates

In reply to this post by Jean Weber
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 like
>>> unpacking to the environments /tmp directory, launching the installer
>>> after unpacking (like it does now), then - and here is the trickey part
>>> I guess - detect a current installation, and offer to upgrade it, or to
>>> 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

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

Roman H. Gelbort Roman H. Gelbort
Reply | Threaded
Open this post in threaded view
|

Re: Automatic Updates

In reply to this post by Scott Furry
El 06/10/10 18:21, Scott Furry escribió:
> Windows becomes the corner case...
> 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.

Great think and great summary, Scott!

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Prof. Román H. Gelbort
http://www.piensalibre.com.ar

10 años usando OpenOffice.org, libre, gratuito y seguro
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

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

Jon Hamkins Jon Hamkins
Reply | Threaded
Open this post in threaded view
|

Re: Automatic Updates

In reply to this post by Charles Marcus
On 10/06/2010 11:06 AM, Charles Marcus wrote:
> On 2010-10-06 1:04 AM, Scott Furry wrote:
>> Any installation method that is deployed, in my mind, must 'respect'
>> the package management of the base operating system.
>
> +1 - So, for most *nix's, this would mean that the built-in LibO updater
> should be disabled, and let the systems package manager take care of it.

Yes, I think so.  For a yum/RPM system, for example, it would be nice if
the initial install of LibO was accomplished by having the user
configure a yum repository (which is simple and short), not by
downloading a huge installation file manually.  Automating this kind of
yum configuration is possible with an RPM.  I.e., the developers create
an RPM that does nothing but configure the user's yum repos, and expose
that RPM to the users via the website.  Then installations and updates
can be as simple as

# yum install libreoffice

and

# yum update libreoffice

The yum package manager would then be able to handle dependencies,
resuming downloads after a broken connection, etc., in a robust way.
Then we wouldn't have to use a ./setup script that bypasses the package
manager, or manually install a desktop menus RPM.

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

Jon Hamkins Jon Hamkins
Reply | Threaded
Open this post in threaded view
|

Re: Automatic Updates

In reply to this post by marcpare4
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 '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.

This functionality is already available in package managers, if we just
take care to use it.  yum, for example, supports delta RPMs.  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.  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
--
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

  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 '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.
> This functionality is already available in package managers, if we just
> take care to use it.  yum, for example, supports delta RPMs.  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.  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
full of 'abandonware'.
Having vast amounts of choice for extensions is wonderful for the
community, so long as these extensions are being actively maintained.
This I think is 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 main 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 package (like being able to edit a Mozilla add-on
install.rdf file to pass a basic revision check) can't be accomplished.
The extension contributor needs to update the extension, or someone else
can pickup maintaining the extension.

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