YaST does seem to check dependencies when uninstalling. Try uninstalling perl, for exampl - you'll get loads of warnings about stuff that depends on it, with the option of uninstalling them, too. However, beware that, even if you say "cancel", it will leave the original package marked for deletion!
You are absolutely right. But I try to find packages that are not required by any other package. I give you an example: I installed gnucash on my system. Because of dependencies gal, guile, phyton, qt, slib, ... have been installed, too. But if gnucash is deinstalled, gal, guile, ... remain in the system. And there is at least one package that is not needed by any other package. I'm trying now to figure out how to find these packages. To find these packages manually is not possible. There are just to many packages. Fabian
In a previous message, Fabian Dost wrote:
YaST does seem to check dependencies when uninstalling. Try uninstalling perl, for exampl - you'll get loads of warnings about stuff that depends on it, with the option of uninstalling them, too. You are absolutely right. But I try to find packages that are not required by any other package.
Ah - do you mean that, after using a different tool to uninstall software, you're left with "orphan" programs that you want to remove? In which case, I don't know whether there's anything to do this automatically. You *could* just go through the listing in YaST, removing everything that you don't want and seeing whether it complains that it's needed. Or are you saying that YaST's dependency checked missed some supporting packages when you uninstalled something using it? In which case, I'd report that to SuSE so that they can fix it! John -- John Pettigrew Headstrong Games john@headstrong-games.co.uk Fun : Strategy : Price http://www.headstrong-games.co.uk/ Board games that won't break the bank Valley of the Kings: ransack an ancient Egyptian tomb but beware of mummies!
Ah - do you mean that, after using a different tool to uninstall software, you're left with "orphan" programs that you want to remove? In which case, I don't know whether there's anything to do this automatically. You *could* just go through the listing in YaST, removing everything that you don't want and seeing whether it complains that it's needed. That's what I mean. Going through the listing takes you like forever. So I'm looking for an easy way.
Or are you saying that YaST's dependency checked missed some supporting packages when you uninstalled something using it? In which case, I'd report that to SuSE so that they can fix it! No, YaST works fine.
In a previous message, Fabian Dost wrote:
do you mean that, after using a different tool to uninstall software, you're left with "orphan" programs that you want to remove? That's what I mean. Going through the listing takes you like forever. So I'm looking for an easy way.
Ah. Of course, the easy answer is "use YaST to uninstall", then you wouldn't have the problem :-) Now that you *do* have the problem, I don't think there's any easy way other than manually going through the list. John -- John Pettigrew Headstrong Games john@headstrong-games.co.uk Fun : Strategy : Price http://www.headstrong-games.co.uk/ Board games that won't break the bank Fields of Valour: 2 Norse clans battle on one of 3 different boards
monday 17 feb 2003, 16:30, John Pettigrew wrote:
In a previous message, Fabian Dost wrote:
do you mean that, after using a different tool to uninstall software, you're left with "orphan" programs that you want to remove?
That's what I mean. Going through the listing takes you like forever. So I'm looking for an easy way.
Ah. Of course, the easy answer is "use YaST to uninstall", then you wouldn't have the problem :-)
Now that you *do* have the problem, I don't think there's any easy way other than manually going through the list.
John
We could/should ask for SuSE to apply something similar to this for YaST: rpm -qa | while read pkg do rpm -ql $pkg | perl -ne 'chomp; next unless -f $_; $e=1; if (-A _ < 6*30) { $e=0; last } END {exit (!$e)}' && echo $pkg done Keep in mind that I didn't write this, and one should probably see over the lists output. It is though a good exercise to try and understand this. -- Leif Mathis Gaup
On Tue, 2003-02-18 at 00:43, Leif Mathis Gaup wrote:
We could/should ask for SuSE to apply something similar to this for YaST:
rpm -qa | while read pkg do rpm -ql $pkg | perl -ne 'chomp; next unless -f $_; $e=1; if (-A _ < 6*30) { $e=0; last } END {exit (!$e)}' && echo $pkg done
Keep in mind that I didn't write this, and one should probably see over the lists output. It is though a good exercise to try and understand this.
You list all packages where none of the files have been accessed in the last 180 days Keep in mind though that a lot of people like to mount their file systems "noatime" for performance reasons.
On Tue, 2003-02-18 at 00:43, Leif Mathis Gaup wrote:
We could/should ask for SuSE to apply something similar to this for YaST:
rpm -qa | while read pkg do rpm -ql $pkg | perl -ne 'chomp; next unless -f $_; $e=1; if (-A _ < 6*30) { $e=0; last } END {exit (!$e)}' && echo $pkg done
Keep in mind that I didn't write this, and one should probably see over the lists output. It is though a good exercise to try and understand this.
You list all packages where none of the files have been accessed in the last 180 days I'm not looking for packages that haven't been used for 180 days. Instead I'm looking for packages that no other packages depend on. That means they can be uninstalled without breaking dependencies. Since rpm checks dependencies when packages are installed and uninstalled the needed information should already be in the rpm-database. A script should be able to perform this. Unfortunately I have no clue about that.
Fabian
On Tue, 2003-02-18 at 01:16, Fabian wrote:
I'm not looking for packages that haven't been used for 180 days. Instead I'm looking for packages that no other packages depend on.
That would be just about all packages the end user actually sees, wouldn't it. For example, I don't think anything actually depends on tuxracer.
That means they can be uninstalled without breaking dependencies. Since rpm checks dependencies when packages are installed and uninstalled the needed information should already be in the rpm-database. A script should be able to perform this.
I seriously doubt it. A script can list all packages that nothing else depends on, but for the above reason I don't think you really want it to automatically remove them Anders
That would be just about all packages the end user actually sees, wouldn't it. For example, I don't think anything actually depends on tuxracer. I tried to remove unused packages manually. Almost all were needed by other packages. And even if there are like 50 packages, it would be a great help.
I seriously doubt it. A script can list all packages that nothing else depends on, but for the above reason I don't think you really want it to automatically remove them No, I don't want the script to automatically remove any package.
Fabian
Anders Johansson
I seriously doubt it. A script can list all packages that nothing else depends on, but for the above reason I don't think you really want it to automatically remove them
What would be useful (in the context being discussed) is, when uninstalling a package recursively identify other packages which the package being removed is the only one depending on them. ie to identify (and optionally remove) other packages which would be made "orphans" by the removal of the (un)desired package.
In a previous message, Graham Murray wrote:
What would be useful (in the context being discussed) is, when uninstalling a package recursively identify other packages which the package being removed is the only one depending on them.
Which is what I thought YaST now did... John -- John Pettigrew Headstrong Games john@headstrong-games.co.uk Fun : Strategy : Price http://www.headstrong-games.co.uk/ Board games that won't break the bank Fields of Valour: 2 Norse clans battle on one of 3 different boards
On Mon, 2003-02-17 at 18:16, Fabian wrote:
On Tue, 2003-02-18 at 00:43, Leif Mathis Gaup wrote:
We could/should ask for SuSE to apply something similar to this for YaST:
rpm -qa | while read pkg do rpm -ql $pkg | perl -ne 'chomp; next unless -f $_; $e=1; if (-A _ < 6*30) { $e=0; last } END {exit (!$e)}' && echo $pkg
<snip>
Instead I'm looking for packages that no other packages depend on. That means they can be uninstalled without breaking dependencies. Since rpm checks dependencies when packages are installed and uninstalled the needed information should already be in the rpm-database. A script should be able to perform this. Unfortunately I have no clue about that.
wow, I didn't realize that YaST has been leaving orphaned files behind until this thread...I have MANY things that have been left behind from when I just "try" certain packages out. OK, a script can do this, here is what I was thinking: You could do "rpm -qR $pkgName >> listA" which lists all the files $pkgName is dependant on. Then do "rpm -qaR >> listB" to list all the dependencies for all files (if you just want to list .rpm's for listB and not all .so files and whatnot, try to run something like: "more listB | egrep -v 'so|bin|rpmlib'" agains listB). If more then one .rpm depends on a file, the depended upon file is listed more then once. So, if anything in listA appears once, and only once, in listB then you *should* be able to remove that package as well. So, this could work in a script. so for example if I want to remove oaf-devel I would do: $> rpm -qR oaf-devel RESULTS: orbit-devel; popt; /bin/sh/; rpmlib(PayloadIsBzip2) <= 3.0.5-1 (ignore /bin/sh and rpmlib...) So, oaf-devel needs orbit-devel and popt to run. So, if I uninstall oaf-devel then orbit-devel and popt are now orphaned .rpm's. Let's see if we can remove them too... $> rpm -qRa >> listB $> more listB | egrep oaf-devel RESULTS: <blank> This means that nothing else depends on oaf-devel. (YaST would handle this part anyway) $> more listB | egrep orbit-devel RESULTS: orbit-devel; orbit-devel; orbit-devel So, orbit-devel is needed by 3 programs (oaf-devel and 2 others) $> more listB | egrep popt | grep -v so RESULTS: popt; popt; popt = 1.6; popt So, three other programs require popt. I used the "grep -v so" due to alot of "libpopt.so.0" files in the list. For arguments sake, if popt only appeared once, then you could remove oaf-devel and popt, but not orbit-devel. You could also make some kind of recursive function, or loop that would keep checking all the dependencies for each. Then list and/or prompt you to remove them also. If I have time later, I'll work on this some more. I would like to remove all that stuff also, in the future. -Jeric -- JericAtSbcglobalDotNetwork 6:51pm up 1 day, 49 min, 6 users, load average: 0.23, 0.15, 0.12 "The right of the people to be secure in their persons, houses, papers, and effects, against unreasonable searches and seizures, shall not be violated..." -U.S. Constitution, Amendment IV, 1791 (Say "NO" to TIA!)
On Tue, 2003-02-18 at 02:31, Jeric wrote:
$> more listB | egrep oaf-devel RESULTS: <blank> This means that nothing else depends on oaf-devel.
No it doesn't. It just means that no rpm builder has listed oaf-devel as a dependency. This is a manually added thing, and *not* guaranteed to be correct
$> more listB | egrep popt | grep -v so RESULTS: popt; popt; popt = 1.6; popt So, three other programs require popt. I used the "grep -v so" due to alot of "libpopt.so.0" files in the list.
All those "libpopt.so.0" entries are also packages which depend on popt. They just don't have "popt" listed as a manually entered dependency. Also, you can't grep for "so". Maybe "\.so". Maybe.
On Mon, 2003-02-17 at 19:46, Anders Johansson wrote:
On Tue, 2003-02-18 at 02:31, Jeric wrote:
$> more listB | egrep oaf-devel RESULTS: <blank> This means that nothing else depends on oaf-devel.
No it doesn't. It just means that no rpm builder has listed oaf-devel as a dependency. This is a manually added thing, and *not* guaranteed to be correct
Well, then you could list all files that oaf-devel contains and run a search for them too, to be more thorough.
$> more listB | egrep popt | grep -v so RESULTS: popt; popt; popt = 1.6; popt So, three other programs require popt. I used the "grep -v so" due to alot of "libpopt.so.0" files in the list.
All those "libpopt.so.0" entries are also packages which depend on popt. They just don't have "popt" listed as a manually entered dependency.
That's what I thought, unfortunately I picked a poor example, and I needed some way to truncate the list to simplify the example. But writing a script for this is definitely doable. I just rambled some ideas out that I thought of off the top of my head, and was in no way meant as an effective solution. Hoping someone might pick up on it and incorporate it in later releases...hint, hint SuSE ;)
Also, you can't grep for "so". Maybe "\.so". Maybe.
Yes, '.so.' would be better, but ideally the .so. files would be used in a more thorough investigation during the script's execution rather then discarded at all...but, like I said above...it was just a quick place to start. -- JericAtSbcglobalDotNetwork 8:04pm up 1 day, 2:01, 6 users, load average: 0.06, 0.03, 0.03 "The right of the people to be secure in their persons, houses, papers, and effects, against unreasonable searches and seizures, shall not be violated..." -U.S. Constitution, Amendment IV, 1791 (Say "NO" to TIA!)
On Mon, Feb 17, 2003 at 07:31:13PM -0600, Jeric wrote:
On Mon, 2003-02-17 at 18:16, Fabian wrote:
<snip>
Instead I'm looking for packages that no other packages depend on. That means they can be uninstalled without breaking dependencies. Since rpm checks dependencies when packages are installed and uninstalled the needed information should already be in the rpm-database.
It does. The issue is extracting that info :)
A script should be able to perform this.
Indeed.
wow, I didn't realize that YaST has been leaving orphaned files behind until this thread...
Methinks the issue is more one of 'orphaned' *packages*, than one of 'orphaned' *files*. Usually removing a *package* should remove all the files that it originally installed.
I have MANY things that have been left behind from when I just "try" certain packages out.
Well it's a complicated issue, and I think the best that could be hoped for was for YaST to be able to come up with potential *candidates* for removal. Package dependencies are all well and good, but they simply don't tell the whole story. Take eterm f.x: jon@a13:~> rpm -q --whatrequires eterm no package requires eterm -but I might've manually set up something to run in eterm, and thus removing it, just on the grounds that no other *package* depends on it, would break this.
OK, a script can do this, here is what I was thinking:
<snip> Well, I was thinking (this is just thoughts, mind you) something to the effect of: Get a list of all known packages on the system, ignoring the version info; rpm -qa --queryformat '%{NAME}\n' > all_rpms then loop over this list, querying each package; for EACH in all_rpms ; do rpm -q --whatrequires $EACH done -or something... I don't know... maybe make a 'secondary' and possibly even a 'tertiary' list, to eventually come up with a list of packages that don't *seem* to be needed. One might feed that to rpm -e --test $CANDIDATES and watch the output, and *then*, finally, make decisions whether to actually go through with removal... I just found this great piece: http://www.rpm.org/max-rpm/s1-rpm-query-parts.html Have a look at the section "--requires: Display Capabilities Required by the Package" (around halfway down) I dunno, but it would be a nice script to have around... I find it hard to believe it's not already been invented? Jon Clausen
I just found this great piece:
http://www.rpm.org/max-rpm/s1-rpm-query-parts.html
Have a look at the section "--requires: Display Capabilities Required by the Package" (around halfway down)
What about this: Write the output of "rpm -qa --provides" to file "a". In this file are now the capabilities of all packages. Write the output of "rpm -q --whatprovides "n-th line of fila "a"" to file "b" If list "a" has n entries, the above commad has to be run n-times. In file "b" are now all packages that other packages depend on. We have to delete entries that occur more than once. Now we have to generate a file "c" which contains all package names. Finally file "b" and "c" have to be compared. The packages that are in "c" but not in "b" are not needed for any dependency and can thus be uninstalled. After thess packages have been uninstalled the script has to be run again Sorry but I cannot write scripts. Fabian
In a previous message, Fabian wrote:
The packages that are in "c" but not in "b" are not needed for any dependency and can thus be uninstalled. After thess packages have been uninstalled the script has to be run again
Except that, as someone has already said, this would end up listing all top-level packages - i.e. the ones you actually use - because nothing depends on them. This gives you still quite a hefty job for manually going through this list. It's probably just easier going through the list in YaST and trying to uninstall something - if YaST doesn't warn you, you're OK deleting it (provided the description shows it doesn't do anything important!). Also, for clarity, can anyone confirm that the 8.1 version of YaST handles this automatically if you use it to do all uninstallations? That is, there should never be orphan packages if YaST is used to uninstall? I'm still not sure whether someone has found orphan packages after using YaST or not. John -- John Pettigrew Headstrong Games john@headstrong-games.co.uk Fun : Strategy : Price http://www.headstrong-games.co.uk/ Board games that won't break the bank Fields of Valour: 2 Norse clans battle on one of 3 different boards
Except that, as someone has already said, this would end up listing all top-level packages - i.e. the ones you actually use - because nothing depends on them. This gives you still quite a hefty job for manually going through this list. It's probably just easier going through the list in YaST and trying to uninstall something - if YaST doesn't warn you, you're OK deleting it (provided the description shows it doesn't do anything important!). Try to step through 200 packages manually in YaST and remember the dependencies. And if you have found one package that no other depends on you have to start over again since the dependencies have changed.
Also, for clarity, can anyone confirm that the 8.1 version of YaST handles this automatically if you use it to do all uninstallations? That is, there should never be orphan packages if YaST is used to uninstall? I'm still not sure whether someone has found orphan packages after using YaST or not. Just try it out: Install gnucash with Yast. Yast will automatically install packages like gal, guile, oaf, slib, Guppi, gtkhtml, python, umb-scheme,.. Then uninstall gnucash and you will find gal, guile, oaf, ... still in you system. And one day you wonder why your drive is full.
Fabian
What about this: Write the output of "rpm -qa --provides" to file "a". In this file are now the capabilities of all packages. Write the output of "rpm -q --whatprovides "n-th line of fila "a"" to file "b" If list "a" has n entries, the above commad has to be run n-times. In file "b" are now all packages that other packages depend on. We have to delete entries that occur more than once. Now we have to generate a file "c" which contains all package names. Finally file "b" and "c" have to be compared. The packages that are in "c" but not in "b" are not needed for any dependency and can thus be uninstalled. After thess packages have been uninstalled the script has to be run again
Actually YaST is doing almost the same, just vice versa. When you install a package it installs all needed packages itself. Fabian
tirsdag 18 februar 2003, 01:00, skrev Anders Johansson:
On Tue, 2003-02-18 at 00:43, Leif Mathis Gaup wrote:
<snip some perl>
Keep in mind that I didn't write this, and one should probably see over the lists output. It is though a good exercise to try and understand this.
You list all packages where none of the files have been accessed in the last 180 days
Keep in mind though that a lot of people like to mount their file systems "noatime" for performance reasons.
As I liked to do. And will again when SuSE 8.2 gets into my hands sometime in the future. But something that do find old nearly unused stuff would be nice. And if it then tried to find other unneeded stuff, then that too would be nice. Shouldn't bee too hard to implement an "rpm -q --whatrequires $rpm" in there. Could give us a small hint on something one can safely(?) remove. The only not so useful rpm the scriprt found here that I know I won't be using is festival. Must have installed that sometime out of curiosity. And if I only could be online all the time, or even some more that today. This modem is killing me, and broadband will get to this place when hell freezes over. -- Leif Mathis Gaup
On Wed, Feb 19, 2003 at 06:22:14PM +0100, Leif Mathis Gaup wrote:
tirsdag 18 februar 2003, 01:00, skrev Anders Johansson:
On Tue, 2003-02-18 at 00:43, Leif Mathis Gaup wrote:
<snip some perl>
I've been messing around with some bash scripting. The approach I take is making some rpm -q's and saving the names of packages that meet different criteria in different lists. And then crossreference these lists, to weed out packages that 'pass' one test but 'fail' another. At this stage the script is probably not very useful, but then it's mainly a 'proof of concepts' thing for me. Currently I'm applying tests to basically find top level rpms (that is one that may be removed without breaking dependencies). The reasoning being that one could run this script, then remove the 'known' rpm (i.e. the app you wanted to check out, and for which purpose some other rpms were installed by YaST or whoever) run the script again, and then diff the result with the result from before, to see if any other rpms have surfaced, that may be 'safely' removed. The tests that are applied at this stage are: rpm -q --whatrequires rpm -e --test All packages that rpm doesn't complain about are put in a sorted/uniq'ed/'crosschecked' 'results' file. *Including* such rpms that it would really not be a great idea to remove. I'm thinking that a kind of 'scoring' based on which rpmgroup the packages belong to might be useful(?), so I might try to come up with something in that direction. Anyway. Next, I've been thinking that it shouldn't be too hard to extend the script look at 'level two' rpms, and *their* dependencies: a.rpm *alone* depends on b.rpm, so can we remove b.rpm? If I can make *that* work, then iterating over that might potentially yield what is basically whole 'trees' of packages that may be taken off the system...
You list all packages where none of the files have been accessed in the last 180 days
This might be yet another test to incorporate.
Keep in mind though that a lot of people like to mount their file systems "noatime" for performance reasons.
Anyone doing that, is already likely to a: know what they're doing b: not being installing apps, just to 'check them out' c: not be interested in this script anyway
As I liked to do. And will again when SuSE 8.2 gets into my hands sometime in the future.
d: Seems I could be wrong about b+c ;)
But something that do find old nearly unused stuff would be nice. And if it then tried to find other unneeded stuff, then that too would be nice. Shouldn't bee too hard to implement an "rpm -q --whatrequires $rpm" in there. Could give us a small hint on something one can safely(?) remove.
"Hint" is the key word in this. What I'm doing with this script is *only* meant as 'hints' about what's on the system. Whatever comes out of the script is meant to be reviewed/considered carefully. Before any action is taken. Maybe in a couple of days I'll put it up somewhere, so you can try it out. Man, this thing just keeps growing... next thing you know it, I'll want to let it take cli -args, and whatnot... should probably 'translate' it to perl before it gets much bigger... ;P cheers, Jon Clausen
participants (8)
-
Anders Johansson -
Fabian -
Fabian Dost
-
Graham Murray -
Jeric -
John Pettigrew -
Jon Clausen -
Leif Mathis Gaup