Some tcz-uninstall results

[bigpcman]

Now that we have a new tcz-uninstall  thanks to Jason's hard work I thought I would report some results. There's no question about it, uninstalling applications is complicated. Since I use samba occasionally and want to uninstall it completely when I'm not using it I chose it as an example. I used the following find command to track what gets installed (outside of tmp) via the date and time..

Code: [Select]

root@box:/# find . -path './mnt/sdc1' -prune -o -path './tmp' -prune -o -path './proc' -prune -o -print0 | xargs -0 sh -c 'for i in "$@"; do if stat "$i" |
grep -q "^Modify: 2009-05-25 20:24:"; then echo "$i" >> install.log; fi; done'
See the attached install log to see what got installed or "touched" in some way. There were 527 entries in the install log. This is outside of tmp mind you.
Here's what's left after the tcz-uninstall --force --purge based on the same date and time. Obviously some of what is left must not be deleted.

Code: [Select]

./etc
./etc/ld.so.cache
./etc/samba/private
./etc/samba/private/secrets.tdb
./home/tc/.ash_history
./usr/local/share
./usr/local/share/doc
./usr/local/share/cups
./usr/local/tce.flwm
./usr/local/tce.flwm/cups
./usr/local/lib/cups
./var
./var/lib
./var/lib/samba/unexpected.tdb
./var/lib/samba/ntforms.tdb
./var/lib/samba/ntprinters.tdb
./var/lib/samba/ntdrivers.tdb
./var/lib/samba/printing
./var/lib/samba/perfmon
./var/lib/samba/account_policy.tdb
./var/lib/samba/group_mapping.ldb
./var/lib/samba/registry.tdb
./var/lib/samba/gencache.tdb
./var/lib/samba/locking.tdb
./var/lib/samba/brlock.tdb
./var/lib/samba/sessionid.tdb
./var/lib/samba/connections.tdb
./var/lib/samba/messages.tdb
./var/run
./var/run/smbd.pid
./var/run/nmbd.pid
./root
./dev/tty1

It's does a pretty good job for an automated tool.  


edit: Some how my check to see what remains after the uninstall either missed the following entries because the time stamp changed after the program was run or they only occur as a result of cycling through install / uninstall. In any event here they are:

Code: [Select]

./etc/cups
./usr/local/include/cups


[Jason W]

Thanks for doing the tests.  But I looked at samba out of curiosity and none of the files in the uninstall.log actually belong to the samba extension (I looked in the mounted /tmp/tcloop/samba3).  /var/lib entries as well as /var/run are files that are created by the running of samba, and the same with /etc/samba/private/secrets.tdb.  Since there is no user.tar.gz in samba3.tczl it should uninstall clean with no files left over.  But a few files out of hundreds being left would be acceptable, and that is what bigpcman was saying.

I thank bigpcman for providing the feedback and motivation to do give some much needed attention to tcz-uninstall.

[bigpcman]

Uninstalling samba demonstrates the fundamental problems with getting a system back to a "pristine" state. The installed files are not easy to track down without human intervention. Why is this? Well here are some of the more obvious problems:

1. The installed program creates more files once the application is started.
2. The installed program modifies some of the files once the program is started (complicates using date and time to find them).
3. The installer overwrites existing files without backing up originals with new content (complicates using file compare for determining what changed in the system).

So if you can't count on date and time or a simple file "existence" compare (not the contents which could take a very long time) then a custom uninstall is required for every application. This seems to be pretty much the case for all operating systems. Each application needs to provide it's own uninstall remedy.

I run two different kinds of systems - a webserver and a development and test system. I try to keep the webserver up as much as possible and not reset it. I'm trying to keep this system pristine without having to reset it. Since Tinycore is so "clean" from the start with a little effort I can generally track down what an application installation has added or changed. So my approach now reinforced by Jason's fine work is to build an install / uninstall wrapper script for the few applications that I use dynamically from time to time to clean the system and regain all of the scarce memory my system has available.

[roberts]

By design. Reboot to a pristine state. Much effort was made to have TC boot extremely fast to support this.  I have never personally supported "package managment" or a traditional hard drive installation, which I refer to "scatter mode". Your results prove my point.

I suppose the method adopted by both Mac OSX and the PC-BSD folks is also an option. The PBI. Very KISS-able. The issue I see with PBIs is that each extenion can become quite large as it is completely self contained. Having multiple copies of many files to avoid dependency hell requires much more hardware. But then it is easy to load and upload, if that sort of thing is an absolute requirement.

[jpeters]

By design. Reboot to a pristine state. Much effort was made to have TC boot extremely fast to support this.  

This thread should remove all doubts  

[Jason W]

Apps create many files when launched and configured, such as ~/.mozilla, ~/.opera, files in /var/tmp, /tmp, /var/run, and so on.  The files in /var could conceivably be placed as empty files in a user.tar.gz so they would be removed upon a forced uninstall, but no extension maker including myself is going to try to account for every possible file that could be created by an app during runtime.  Ccache lets you choose which location to store your cache, and there is no way for an uninstaller to know where you have placed your cache so as to remove it. And stuff in /tmp and /var is temporary and not there on reboot. Config files are left in place by distros like Debian.  Most other distros base their uninstallation on which files were actually installed, and not ones that were created by the running of the app. The issue of files created during runtime are going to be there whether a modular shared approach in the extension is used or the extension is installed in a self contained directory. 

Tcz's by default don't overwrite existing files or symlinks, so the issue of files getting overwritten is not there unless those files are in the user.tar.gz.  Tcz makes it hard to trash your system by installation or uninstallation except in the case of a poorly made user.tar.gz.  But removing packages by it's very nature brings in HD-install elements to the system, like leftover files.  That just goes with the terriroty. But the uninstall option is there for those who want to use it.  I like to test and then uninstall new extensions and be able to update other ones without rebooting, but it is nice to know a guaranteed clean system is only a reboot away.

Features and safety checks have been introduced to tcz-uninstall without really adding too much to the complexity.  But aside from other WM support which will be invisible to the user, I think that the feature set is complete. 

[bigpcman]

I for one Jason, think the tcz-uninstall tool is an excellent utility that I now count on.  I will continue to build install / uninstall "wrapper" scripts for the "bloated" apps like samba to remove them without needing a reboot to get back to a near pristine state. Reboots on my little web server for me are painful because they must be done via a usb floppy and the entire floppy must be read into ram before the boot process can be started to avoid bios usb conflicts. Reboots on my development system are long because there are a lot of apps that get loaded.  I would agree my situation is not typical but it is what it is.  

[Juanito]

..."bloated" apps like samba to remove them without needing a reboot to get back to a near pristine state.

BTW - I looked at samba2 as it would be much less bloated, but, as far as I can tell, it does not support cifs...

[jpeters]

I think that the feature set is complete.  

..what, no sound?

I will continue to build install / uninstall "wrapper" scripts for the "bloated" apps like samba to remove them without needing a reboot to get back to a near pristine state.

I was also thinking along those lines....for sets that are installed/uninstalled regularly a simple script would be much faster, and you could get everything.  The ability to update without having to reboot is a real plus (I know......I posted that already everywhere.....)