Date: prev next · Thread: first prev next last
2010 Archives by date, by thread · List index


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 <scott.wl.furry@gmail.com> 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<grakic@devbase.net>  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
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/

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

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.