Hamish: > > * wxGUI extension removal: > > I don't think it is very wise to rely on a volatile > > generated file on a remote server to decide which files to > > delete on my local machine. ... > > Was there some win32 reason to do that, or..?
Martin: > The main reason is that some of the modules install some > extra components which can be hardly guessed by `g.extension` > module (see `grass7/r.modis` and others). .. > Well, relay on generated files on the remote server when > deleting the files is not a "wise" idea. ... and this aspect would bite us often: >> and may well change between the time of install and the >> time of removal, > Probably `g.extension` should install also some metadata > file locally about which files to remove when uninstalling. to be honest I'm not really worried if option=remove left over a few orphaned files in corner cases, as remove= doesn't get run very much anyway. shrug. how about $addons/docs/manifests/g.module.files or g.module.list? another question to consider is if it is desired to remove addons which have been installed system wide? (if run with suitable admin rights) I'm not completely sure that it is, probably it just feels weird as we've never had a 'make uninstall' before. > Then `g.extension ext=<module> ope=remove` would just report > which files is going to be removed and `g.extension > ext=<module> ope=remove -f` would remove them. Seems to be > better solution for you? Sounds alright, but is it overkill? (again, it's not something I would have bothered with, but I don't really mind) Hamish: > > * wingrass uninstall now also removes the addon dir? ... > > there should at least be a "Are you really sure > > you want to do this?" dialog, as non-accidentally > > deleting users' personal scripts will not be good for > > business. Martin: > I think that the whole $APPDATA\GRASSX should be untouched > when uninstalling winGRASS. I will changed the installer > according that. perhaps like some other Windows uninstallers it could have a tick box in the dialog wizard: "Also remove configuration and addon modules?" or, perhaps break that down into two tick boxes? one for config files and the other for addons? (As seen by Johannes's post yesterday to grass-dev there is demand for an in-path home for personal addon scripts.) the main thing to ensure is that left-over temporary files get removed. the config files are tiny, but the accumulation of temp files can be huge. I think we've fixed the wingrass file delete bug now so it won't be as bad as it used to be, but it is worth checking in case of blue screens and unclean exits. (OT: also abandoned /tmp/grass7-$USER-$PID/ dirs seem quite common; we're missing a cleanup() catch somewhere) many shrugs, Hamish _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
