Re: [tdf-discuss] 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 <scott.wl.furry@gmail.com> 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<scott.wl.furry@gmail.com>  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<grakic@devbase.net>    
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
> > > > > discuss+unsubscribe@documentfoundation.org
> > > > > 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
> > > discuss+unsubscribe@documentfoundation.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/discuss/
>
> --
> 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 b
e
> deleted.
> List archives are available at
> http://www.documentfoundation.org/lists/discuss/
--
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/