Tiny Core Linux
Tiny Core Extensions => TCE News => TCE 1.x => Topic started by: Jason W on March 02, 2009, 03:19:52 AM
-
This is tce-uninstall. You must be using the latest tinycore-1.2rc2 release candidate to make use of this extension.
Title: tce-uninstall.tce
Description: Utility to uninstall tce extensions. (TESTING)
Version: 2009/03
Author: Jason W
Original-site: www.tinycorelinux.com
Copying-policy: Free
Size: 2K
Extension_by: Jason W
Comments: Command tce-uninstall brings up menu of installed tce
extensions that can be uninstalled. You must be running in either
scatter mode, or PPI mode that was booted with the "local=hdxx"
boot option for this extension to be used. This uninstaller is
almost irritatingly conservative and will not disrupt a running system
as extensions with files in use will not be uninstalled. Dependencies
are also taken into account. The uninstaller will not uninstall extensions
that have any files above /usr/local as to remove them can leave a broken
base system.
----
A --force option will override all of this and give you
full control. "tce-uninstall --force OSS" will remove OSS.tcem alone
without checking for dependencies, files above /usr/local, or files in use.
Use the extension name without the suffix, like glib2 or OSS and do not
include the .tce(l,m) when using the force option. Mind youl, be sure you
know what you are doing if using the --force option as if you use it and break
your system, you get to keep both pieces. It's use is not recommended
but for carefully upgrading libraries or things like that.
-----
This utility uses the extensions' .dep files to process dependencies. In
the case you deleted your .dep files from /usr/local/tce.list or you
installed the extensions outside the use of the appbrowser, running the
command "tce-uninstall --gendeps" will fetch the .dep files for the
extensions you have installed so you can take advantage of dependency
tracking during uninstall.
This extension is PPI compatible.
Change-log: -------
Current: 2009/02/28 First version.
-
I sure hope that every extension has a complete dep list, because it may be difficult to figure out why an extension suddenly doesn't work after tce-uninstall deletes shared dependencies. Wouldn't rebooting after deleting the extension from the tce folder be a lot safer?
-
Just how is deleting an extension from the tce folder and rebooting different from uninstalling the extension? The exact same thing is happening in either case. And that is assuming running in RAM mode, which is not a mode that supports uninstalling.
There is one more check that could be added to the dependency routine, but it would slow it down even more than it is. Any extension being broken by the uninstaller is unacceptable and if there are such cases I would fix the uninstaller or pull it if it can't be fixed. Though I have found no problems with uninstalling any extensions, this is still testing material and to be used with the assumption of mild risk.
In any case an extension is broken by missing dependencies, restoring them is as easy as clicking on the extension in the appbrowser and the missing deps will be installed. But like I said that is not an acceptable outcome of the uninstaller.
-
Just how is deleting an extension from the tce folder and rebooting different from uninstalling the extension? The exact same thing is happening in either case. And that is assuming running in RAM mode, which is not a mode that supports uninstalling.
Maybe I don't understand the process. Let's say I have python-devs.tczl installed, and then load an extension that needs it. I decide I don't need the extension, so delete it from my /tcZ folder. When I reboot, the extension isn't there, but python-devs.tczl still exists. Now I repeat the process, but uninstall with tce-uninstall, which has python-devs.tczl on its dep list. I was assuming that dependencies get deleted?
-
First, only tce extensions are taken into account by the uninstaller. Tcz is left alone. Let's take glib2 for example. Say it is dependent on expat2.tcel (it is not but for this illustration). Assuming none of it's files are in use by other apps, use the uninstaller to try to uninstall it. What you will see is a list of installed apps that depend on glib2 - on my box now it is atk, emelfm2, gqview2, gtk2, leafpad, and pango. Three options are then presented:
1. Do not uninstall glib2 (recommended)
2. Uninstall only glib2 (for advanced users only).
3. Uninstall glib2 and those that depend on it.
Dependent apps are offered up for uninstall, not dependencies. Expat2.tcel would be left alone. It wouldn't be good to uninstall dependencies "below" an extension, but it is good to let the user know of the dependent apps "above" it so they won't get broken. Of course, if a .dep file is incomplete, then breakage is possible somewhere. But that would be a case of a broken dep file rather than a broken uninstaller.
I hope this clears it up a little. Sorry my response earlier was snippity.
-
Sounds good! Thanks for the explanation. You must have put some time into this, which is much appreciated...
-
This is a very interesting addition, and quite unexpected.
Without having looked at it yet.....
I'm assuming it makes use of /use/local/tce.installed. I have a local boot script in that directory, so would that show up as removable?
With the exception of tcem packages, all of my files in tclocal were installed manually. I wanted to check each tce package contents to see what, if anything, was being overwritten or installed into the base system. I moved some files from base to tclocal, and I didn't bother with the /usr/local/tce.* files, so I guess that might be a problem for me if I ever wanted to use this tool.
-
Actually, /usr/local/tce.installed/* files are not used though the entries are removed during an uninstall. Extensions have to have been loaded with the file list creation supported as the latest release candidate does to make use of the uninstaller. So existing tclocal installaions do not have the file lists available and cannot make use of the tool. Boot scripts in /usr/local/tce.installed that are not part of an uninstallable extension are not affected. /usr/local/tce.list is the directory where all info for the uninstaller is taken.
In other words, extensions can be installed with tce-load, the appbrowser, or during boot by tc-config as long as "local=hdxx" was specified during boot and they will then show up as uninstallable if they meet the other criteria. If there are files in an extension chosen in the uninstaller outside of /usr/local, the uninstaller will exit with such error message. If files in the extension are in use, the uninstaller will exit with a list of processes using files in that extension.
I will look over it once more as I may have not included the check for files above /usr/local for each dependent app being uninstalled when such is chosen.
-
/usr/local/tce.list is the directory where all info for the uninstaller is taken.
I don't have that file; I've got tce.installed, /.menu, /.icons
-
Latest TC release candidate has to be used or that directory will not be created.
-
why this tce doesn't work with tcz?
-
Though there is a tcz-uninstall avalable, there are going to be some changes that affects this uninstaller and will make it available across all supported modes. Given that, I may combine the two uninstallers to work with both tce and tcz since many run a combination of the two. That way dependencies are accounted for whether they are installed as tce or tcz. I will shoot for that in mind and hopefully come up with a solution in the coming week or so.
Though I will leave tcz-uninstall as an extension since some folks will not want to uninstall tce's.
-
I did update tce-uninstall to work across all running modes by fetching the file lists from the server, but I will leave tce-uninstall and tcz-uninstall as two seperate utilities since the two extension types are two very different animals. This uninstaller was made to mirror the install process and use the same dep files. The dep files work only with the same extension type as they belong to, and the uninstaller should too. Keeping the uninstall utilities seperate keeps things more congruent with the base system. Not that having a universal uninstaller is a bad idea, I did ponder it for a while.
-
I still don't quite understand how uninstall works. For example, if I load OO.tcz from my optional foldler, it has expat, fontconfig,and libxm as dependencies. After loading/uninstalling, nothing is added or removed from /tcZ, and the deps remain to be loaded upon reboot. I don't know if things would be different if OO was installed directly from the appsbrowser into tcZ. If the deps aren't being used by something else, they would be deleted? Only if they were installed with OO? Sorry to be dense about this.
-
You're not being dense. There are these checks that have to be satisfied by the package being uninstalled and it's dependent ones if they are being removed too: check for files in use, check to make sure all files are beneath /usr/local.
If you are running a mixed system, tcz along with tce, then only tce installed extensions are dealt with. Tcz-uninstall is to be used to remove them. The tcz uninstaller has a check to see if files are in use, but dependencies are not dealt with. I can add dependency removal and will when I have some time making it the same as tce-uninstall.
It makes no difference how the extensions are installed, the dependencies are gathered by the .dep files that are downloaded when the uninstaller is first run. Say you install OOo, expat, fontcofig, and libxml as tce's. Bringing up the uninstaller and removing OOo will not bother those other three since they are dependencies of OOo. Nothing depdends on OOo so as long as it's files are not in use and it is all beneath /usr/local it will simply be uninstalled. If some of the dependent apps of a tce being removed are tcz's, they will not be dealt with but they can be removed by tcz-uninstall.
The uninstaller does not remove extensions themselves that reside in your */tce directory. If you are running totally in RAM, they are removed from /tmp/tce upon loading. I could add an extra dialog question that would ask if you want to remove the extension(s) in the tce directory as well as uninstall them from the system. That would make it easier to maintain your /tce folder selection instead of picking through it manually. But I don't want to mess with the contents of the optional directory since those apps are loaded manually at will.
-
The uninstaller does not remove extensions themselves that reside in your */tce directory. If you are running totally in RAM, they are removed from /tmp/tce upon loading. I could add an extra dialog question that would ask if you want to remove the extension(s) in the tce directory as well as uninstall them from the system. That would make it easier to maintain your /tce folder selection instead of picking through it manually. But I don't want to mess with the contents of the optional directory since those apps are loaded manually at will.
That was where I was getting confused, because I think the installed deps get placed automatically into /tcZ with "install selected" option from appsbrowser. If so, the user would have to know what deps are installed from the deps file (and what other apps share them) before deleting them manually. If nothing is done, they get reinstalled at reboot.
-
I'll add the option to delete /path/to/tcedir/extension.tce* sometime this next week when I get time. I'll also work these same features into /tcz-uinstall. That would allow for maintaining the tce directory contents in keeping with dependencies. I am still thinking of merging the two utilities to make a more seamless uninstall experience for those with mixed systems. It would not add much more complexity to the scripting nor cause more risk of system inconsistency.
-
I'd be happy with rules like:
If the app being uninstalled is NOT in the default /tcZ/tce directory (eg, /optional, etc), then DO NOT delete any dependencies that may be listed in the default directory.
If the app being uninstalled IS listed in the default directory, provide option to delete the app along with dependencies that are not in use after app is uninstalled.
-
I think you are still unclear about the dependencies issue because your first rule is a situation that would most likely never happen. Let's say one wants to uninstall gtk1 and it is in the optional directory and you manually installed it first then XMMS. XMMS installed and the .tce is still in the main tce directory. So according to the first rule mentioned XMMS would not be able to have it's .tce deleted since it resides in the main tce directory. But now you go to reboot and XMMS is broken by a missing gtk1 since the XMMS tce is still in the main tce directory. Mainly, the optional directory is for end use apps that you sometimes use, not libs the system is built with.
Or let's take the reverse and more likely scenario. You have gtk1 installed and in the main tce directory. XMMS is installed and left in optional. You go to uninstall XMMS and gtk1 is not part of that picture as it is a dependency, and not a dependent app. I think dependency vs dependent app is where there is still some confusion. Uninstall gtk1 when you also have XMMS installed and you will get a dialog telling you that XMMS is dependent on it. Uninstall XMMS and you will get no such offer to uninstall gtk1.
In other words, the first rule you mentioned would leave you rebooting into a broken system if you uninstalled the lib or app not installed from the tce directory that has dependent apps with their tce's in the main tce directory. If we are going to offer to delete .tce's at all, dependent apps must get deleted from the tce directory if one makes the decision to delete the .tce's or a broken system upon reboot will result. I must assume that one is not installing low level libraries outside of the tce directory and then placing apps that need that lib into the tce directory. But even in that case, if one chooses to delete the .tce's of both the uninstalled app and it's dependent apps if they are being uninstalled then those dependent apps would need to be deleted from the tce directory even if the main uninstalled app/lib was not in there or a broken system upon reboot will occur.
And avoiding a broken system is the goal in the first place.
-
This is getting confusing :) I'm not sure why someone would be using /optional for dependencies, but in the first case there would be the option to uninstall gtk when XMMS was uninstalled from /tcZ. I would expect that core dependencies would be in the default folder anyway.
If gtk was installed in /tcZ and I uninstalled XMMS from /optional, gtk would remain. Personally, I'd like to use the /optional directory for loading/unloading temporary apps without worrying about deleting dependent libraries from the default folder.
I'm not going to worry about somebody placing core libraries in the /optional folder and arbitrarily uninstalling them. Sorry about the confusion.....
-
It's all good, I'm sorry for making it confusing. The deletion of tce's during uninstall as well as the dependency resolution will hopefully follow a logic that is agreeable. I will add the deletion of tce's option and we can see if it is something we like. It can always be reverted or fixed if it does not function like expected.
-
Updated to delete extension and associated files from active tce directory upon request.
-
Fixed some bugs: Creating /usr/local/tce.list if not existant, showing all entries of installed tce's, added a .dep file to include needed apps (lsof, wget, openssl).