"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 <[email protected]> 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<[email protected]> 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<[email protected]> 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 >>>>> [email protected] >>>>> 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 >>> [email protected] >>> 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 > [email protected] > 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 [email protected] 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/
