Tiny Core Linux
Tiny Core Extensions => TCE Talk => Topic started by: robc on January 10, 2009, 01:39:03 AM
-
Has there been any discussions about a tce uninstall package or script?
I think this is possible (except for maybe in packages that overwrite base files). There is already a file generated in tce.installed so tc knows which extensions are installed. This file can be used to store a list of files contained by the tce. This list can be used to remove the files (and possibly repack them into a tce extension).
This would be useful for those with limited RAM so they can remove extensions that they are not currently using to install another extension that they need to use temporarily. Or if you want a compile environment with compiletc but don't need it later then you can remove it.
Does this sound doable or something that may be desired?
-
It is doable, but tcz's may be more suitable for your situation?
I think this is the same scenrio with .dsl 'uninstalls'...
-
Our solution for limited ram systems is to use tcz type extensions. There is a tcz-uninstall.
tce load into ram, trying to implement a full package management system also in ram would further reduce available ram. While TC supports limited persistency it is not the focus.
-
maybe it could then be done as an extension? (like the tcz-uninstall one)
-
maybe it could then be done as an extension? (like the tcz-uninstall one)
yeah, but the real issue is that you "uninstall" a tcz by unmounting a loop, possibly deleting a file or two. to uninstall a tce, you'd have to delete many files and folders, and tce is not even designed with this in mind. it wouldn't be impossible to rig some utility as an extension to try to do this, but it's messy, where doing it with tcz is simple and natural.
-
I think it also removes the symlinks that were generated during tce-load.
-
Like Robert has said, package management beyond installing extensions with their dependencies does not fit in with TC's goals. Though rebooting into a clean known state is the correct way to rid your system of unwanted extensions and other stuff, I have to admit I occasionally have wanted to be able to uninstall a .tce extension and have toyed with the idea. A file for each extension that contains a list of the files installed by that extension would make it possible to write a routine that uninstalls tce's. But there are two things I can think of right now that tcz-uninstall takes into account that cannot be done with tce's.
For one thing tcz's never overwrite base system files unless those files are contained in a user.tar.gz. That is by design and is a safety measure. And the files in the user.tar.gz are not removed during uninstall since they are real files that may be overwriting files in the base system and are therefore not wise to remove. So uninstalling a tcz is pretty safe and has almost no chance of messing up the base system. One of the good things about a tce is it installs by force, overwriting anything in it's path. That is valuable especially for extensions that need to overwrite base items, but makes uninstalling such an extension not a good idea. It can break the system.
Another thing is it is possible to tell if a tcz extension is in use and in that case the uninstaller exits. There is no way to tell if the files in a .tce are in use, at least not that I know of. So if a .tce is uninstalled, one may be removing files that are in use. Again, not a good thing.
These two reasons alone make uninstalling a tce a risky proposition.
-
What I would like is not a tce uninstall,but a routine that deletes all the uneeded tce/z
-
What I would like is not a tce uninstall,but a routine that deletes all the uneeded tce/z
where are the unneeded tce's? as far as i know tc deletes them anyway, unless you are using the tce= boot option (which you only do if you want to keep them.) there are no unneeded tcz's, as they are mounted until you use tcz-uninstall.
-
So if a .tce is uninstalled, one may be removing files that are in use.
I agree there is a level of risk that a user may try to remove files that are in use, though it is the user that is removing these extensions and they should know what they are using and what they are not. In the end it is the users responsibility to know what is and isn't being used on their system. I would never put out a package like this without a warning/disclaimer that says it should be used at their own risk and they need to understand what they are removing.
A file for each extension that contains a list of the files installed by that extension
This was I originally proposed in the first post...but you can also generate a file list from the .tce package itself. So an uninstall package designed for tces could require the actual tce package (i.e. compiletc.tce) be present in the user's tce/ directory. If that is done then the only packages that can be uninstalled would be those that are already installed AND have the package present in tce/.
Our solution for limited ram systems is to use tcz type extensions.
I am not questioning any decisions of the TC staff. I am only curious if this is a possibility or if there is even a desire for such a tool.
-
To satisfy my curiosity, I adjusted my local tce-load and tc-config to create a list of files for each extension loaded in a manner that does not increase load time to see what the cost in RAM would be. The bad news is that for the 44 extensions I have loaded, their list files occupy 200kb of space which would be in RAM if one were not using tclocal.
I have to admit that for my own use being able to uninstall tce's is kind of neat, but it wouldn't be fair to cost everyone in RAM usage to have this feature since it would require a change to the extension load routine in base to make use of an extension to uninstall tce's. If it could be done solely in the context of an add-on extension that would be different.
It is one of those things that could be done but not without a cost to one of TC's central goals. As well as the risks mentioned that would exist uninstalling certain extensions.
-
suppose tce-load checks if [ -f ]; . . . /usr/bin/tce-uninstall and tce-path-from-boot-option/tce-uninstall.tce. if either one exists, it will create the logs. i say either one because tce-load also loads on boot, so unless tce-uninstall.tce opens first, /usr/bin/tce-uninstall won't exist yet.
-
I have to admit that for my own use being able to uninstall tce's is kind of neat, but it wouldn't be fair to cost everyone in RAM usage to have this feature since it would require a change to the extension load routine in base to make use of an extension to uninstall tce's. If it could be done solely in the context of an add-on extension that would be different.
The base routine to install extensions does not have to change. Instead the tce-uninstall package would create its own temporary list of files from the extension itself and when it is finished removing the files it would then remove the temporary list that it created. Though that would mean this extension would only be useful to those who have the package downloaded onto their system, or it could grab the extension from the repository itself.
suppose tce-load checks if [ -f ];
I agree with Jason that the base system should not have to be changed....after all, that is what extensions are for.
-
I agree with Jason that the base system should not have to be changed....after all, that is what extensions are for.
me too, but it's easier to write a simple extension if one line of code is added, and it would not do anything at all unless /usr/bin/tce-uninstall or tce-folder-from-boot-code/tce-uninstall.tce were found, in which case tce-load would run a script that was part of the extension.
it's possible to do it in an even more convoluted way that doesn't require 1 line of support in tc. you could have the extension itself replace tce-load with a modified tce-load. i doubt roberts would prefer tce-load be replaced by an extension. plus this has the problem i mentioned of it only applies after stored tce's are loaded on boot.
if anything it assumes that someone really wants to create tce-uninstall, which most people probably wouldn't if they knew why. but adding one line to tcb is probably the easiest and most efficient way to support it.
-
One of the things that has always bothered me about uninstall programs is that they leave behind all the junk that was created by the parent program. Files that end up in /home or perhaps in the backup file. It sure would be nice to have a "running" list of all the files that are associated with any installed program or some sort of "scanner" that could provide the list.
-
it's easier to write a simple extension if one line of code is added
It would make it insignificantly easier to write in a script or C and it would put a burden upon roberts to change tce-load as well as increase the size of extensions that are used. By having the uninstall package/script create its own file list then the file list would be temporary, would not increase the size of the packages and would only take 1-3 lines of code.
-
It would make it insignificantly easier to write in a script or C and it would put a burden upon roberts to change tce-load as well as increase the size of extensions that are used.
not really. adding an if line to tce load is not burden. the if line (any of us could write it, even me) would just look for two files, if it found one of them it would run a script named /usr/bin/genlist (or whatever) and genlist would be written by the extension author. if it didn't find the files, it would do nothing.
it helps to have tce-load call the list creator. you do not need to add 1 byte to the extensions themselves, the list creator could simply do a before and after... although that gives me an idea. what if the list generator calls tce-load instead? that could be done. the reason it's not good to replace tce-load itself is that roberts may want to update it, and it's no good having an extension that replaces tce-load with an outdated modified version.
that would be a burden, or at least an annoyance. but what i proposed hypothetically only involved adding one line to tce-load, and nothing to the extensions themselves. you could probably write a script that generates a filelist, calls appbrowser, generates a second list, runs diff, etc.
but do you see the problem with that idea? it still means that tce-load will not (optionally) register the extensions loaded on boot, so tce-uninstall wouldn't be able to uninstall them. in order to make it work without remastering, you may need that one line of code added. a line that will do nothing if the tce-uninstall extension does not exist.
-
In practical terms, for me as a user, this means that I cannot experiment with tce packages since there is - from reading this thread - no way to remove them. This seems different from other distros and rather against the point of linux, which is meant to be free - which includes choices in loading and removing packages. And I'm sure my needs will change over time.
Also, is it possible to uninstall tcz packages by simply deleting them? This would give them an advantage over tce.
On another note - I have installed minefield as tce and it has added quite a bit to my boot time. Would it have been better to install it as tcz - in terms of boot times?
Finally - if I did install minefield as a tcz, some of its dependencies will be tce. Does this matter?
Sorry for all the questions - this is all a bit new to me!
-
Tcz packages can be uninstalled with the tcz-uninstall tool - it's available as a tce ;)
Technically you can uninstall tce's, by removing it and rebooting, which is good enough response time.
Loading time depends greatly on the package, some are faster as a tcz, some are not.
Having tce dependencies with a tcz extension does not matter, they all mix-n-match (except for automatic dep loading, where a tcz can only depend on tcz-type extensions, but that's only for the appbrowser)
-
..and I guess tce extensions could also be manually removed without re-boot by extracting the file listing from the extension tarball and deleting the files listed.
-
This seems different from other distros and rather against the point of linux, which is meant to be free - which includes choices in loading and removing packages.
Different, yes. TC is on its own path. I would definitely not say it's "against the point of linux", not in the least. You do have freedom...more so than with most other distros. Freedom is about being able to use, share, and modify the software for whatever purpose you want, which is often so obscured by mindnumbingly mind numbing graphical interfaces and interdependent applications that the process of making changes sometimes seems not worth the effort. Have you ever tried disabling the graphical login manager in Debian? It is surprisingly complex, almost painfully complex, when it traditionally should be a simple matter of changing a single digit in inittab.
TC has opted for simplicity and small size; rather than providing a tool for every desired task, you have the freedom to add and change what you like. Remastering is quicker and easier in TC than in any other distro I've seen. The incredibly fast boot time means you can quickly reboot to return to a clean state in seconds. The tce boot option allows you to set up multiple preset systems with custom collections of applications, using the same base system for all of them. And, as was mentioned, the tcz extension type along with the tcz-uninstall extension allows you to test applications and easily remove them without a reboot
EDIT: seems I was wrong about the login manager. I was going by a result from a google search, which gave a lengthy and overly complex explanation that involved modifying multiple files. As it turns out, simply removing the kdm symlink from the desired rc directory is good enough. That is also something that Debian seems to make complicated, though. In the rc.* readme file, it says To disable a service in this runlevel, rename its script in this directory so that the new name begins with a 'K' and a two-digit number, where the number is the difference between the two-digit number following the 'S' in its current name, and 100. To re-enable the service, rename the script back to its original name beginning with 'S'.
I don't know if that's a joke or not.
-
kerpob: as was probably already mentioned (just giving credit,) there are only two situations- neither of which most uses of tc will encounter- where you "cannot remove" a tce package:
1. you do not want to reboot (removing a tce package is usually as easy as deleting it from your tce store if you have one- if you don't there's no need to delete- and rebooting)
2. you have done a "traditional" install that goes somewhat against the intended design of tc- personally i think you should feel free to do this, although the way tc is designed (to focus on modularity) you can find yourself going uphill a lot. in this instance, ppi (read "core concepts") is a good compromise but also makes removing tce's a challenge.
it's not "impossible" to install tce packages then, either. but since a tce* package is basically a tar.gz, when have tar.gz files (in any distro) come with an uninstall option? tcz* packages are mounted, so removing them is about as simple as unmounting and deleting- saves rebooting.
if you want to experiment with tce's (adding and then removing them) the best options are frugal install, poorman's install, or just using the standard livecd boot with (or without) the tce=hdXY option.