Stefan van der Eijk <[EMAIL PROTECTED]> writes: > Yep. So you would like a switch / option to be added that when you remove foo > (urpme foo --something) that it'll suggest to remove libbar and libmoo as wel. > Hmmm... Interesting. What critera will be used to remove those packages? Should > start with "lib"? Only the top-level ones? > > Dependency example: > A Requires B > B Requires C > B Requires D > C Requires D > E Requires D > > urpme A would also suggest to remove B? > urpme A would also suggest to remove B and C? > > urpme A cannot remove B, C and D, since E depends on D. > > question is, how deep do you want this to go? Do you want to prune until you hit > a branch (ie E)?
There is features request to improve find_leaves in order to help cleaning system, this can be intergrated along with urpme so that some packages may be removed automatically. > I've been playing with this myself a bit. And decided to take a different > aproach: > > I made a list of packages that I want installed on my system, and then run a > script (http://eijk.homelinux.org/build/bin/min.sh) against it. The packages > that I can de-install will be printed to your screen (or with "./min.sh remove" > they will be removed). I am running into a limitation in urpmq with this script. > If you get have a Requires that can be satisfied by two Provides (automake, > webfetch, etc) then urpmq cannot figure out what the dependencies of these > packages actually are: I think you have a good approach, to avoid removing anything, I would like to add a file that describe packages that will not be uninstalled, by default this file could include basesystem alone, but removing it will be very dangerous. > How it makes the descision is open for discussion. Snoop into the rpmdb on the > system to see if one of them is installed, if not make a choice (random?). I can add such switch to help resolving choices and make itself the choice when no available. Regards, Fran�ois.
