Summary: | No uninstall script | ||
---|---|---|---|
Product: | Koha | Reporter: | Chris Cormack <chris> |
Component: | Installation and upgrade (command-line installer) | Assignee: | Galen Charlton <gmcharlt> |
Status: | CLOSED WONTFIX | QA Contact: | |
Severity: | enhancement | ||
Priority: | P4 | CC: | chris, dcook, kyle, wizzyrea |
Version: | Main | ||
Hardware: | All | ||
OS: | All | ||
Change sponsored?: | --- | Patch complexity: | --- |
Documentation contact: | Documentation submission: | ||
Text to go in the release notes: | Version(s) released in: | ||
Circulation function: | |||
Attachments: |
Untested uninstall script edited in Windows
Revised partially tested, but still a bit buggy non-patch file Revised untested non-patch file - Prevent package uninstalls now |
Description
Chris Cormack
2010-05-20 23:31:27 UTC
Restoring where "Previous assignee was mjr@ttllp.co.uk" Created attachment 12435 [details]
Untested uninstall script edited in Windows
This bug caught my attention. Here is my initial, rough draft attempt. If anyone wishes to polish it up, test it, comment that it is missing something, that would be great. The measure of good software, in my books: installs easy, does what it says, and uninstalls easy. Hopefully, this script will work towards making the last point a reality.
Created attachment 12451 [details]
Revised partially tested, but still a bit buggy non-patch file
Fine, I'll take the bug. I haven't patch-i-fied this yet. I've only run this on a packages installation. The koha zebra daemon removal part still needs some work. But once I'm happy with my testing on packages, I'll work on testing it on a git install. Then I'll go old-school with a tarball install.
I probably need to add logic to exclude the git clone directory from deletion.
Any other ideas or feedback? Feel free to test tweak and post a patch if you want. :)
Created attachment 12606 [details]
Revised untested non-patch file - Prevent package uninstalls now
I was told that anything that even attempted a packages uninstall would not pass QA, so no packages processing (except detection) is done.
MJ Ray's security rant made me revisit sections of this to remove as many sudo's as possible. Not all have been removed.
The Ubuntu instructions create an /etc/cron.d/koha cronjob using sudo. Should all git and tarball installs use user crontab files and not /etc/cron.d /etc/cron.hourly or /etc/cron.daily? Feedback needed.
Why would we not use koha-remove <instance> and then apt uninstall koha-common then apt autoremove? I'm not sure this bug needs a fix anymore? A developer is going to be using either a devbox or a koha-testing-docker; an average user hopefully will be using Debian packages as advised in our documentation, and certainly, support vendors will be using the packages as well. (In reply to Liz Rea from comment #5) > Why would we not use koha-remove <instance> and then apt uninstall > koha-common then apt autoremove? > > I'm not sure this bug needs a fix anymore? A developer is going to be using > either a devbox or a koha-testing-docker; an average user hopefully will be > using Debian packages as advised in our documentation, and certainly, > support vendors will be using the packages as well. I tend to agree, but isn't installation from tarball still supported? (In reply to Kyle M Hall from comment #6) > (In reply to Liz Rea from comment #5) > > Why would we not use koha-remove <instance> and then apt uninstall > > koha-common then apt autoremove? > > > > I'm not sure this bug needs a fix anymore? A developer is going to be using > > either a devbox or a koha-testing-docker; an average user hopefully will be > > using Debian packages as advised in our documentation, and certainly, > > support vendors will be using the packages as well. > > I tend to agree, but isn't installation from tarball still supported? I'm with Liz on this one. While people can install Koha from a tarball, I can't think of any Linux software that has a uninstall script when installed from source tarball... |