* Danek Duvall ([email protected]) wrote: > On Wed, Jun 17, 2009 at 09:43:37AM -0700, Glenn Lagasse wrote: > > > If I install foo and bar isn't installed then both foo and bar get > > installed. If I uninstall foo (using -r) and bar isn't a dependency for > > anything else I'd expect bar to get uninstalled as well. If both foo > > and bar are installed and I uninstall bar I'd expect a warning saying > > that bar is a dependency of foo. > > > > Why does it work the way you describe? I'm not really seeing the logic. > > Think of the dependency tree. From any given package, you can uninstall > recursively in either direction. A simplified example: > > A B > \ / > C > / \ > D E > > That is, A and B are leaf packages, both depending on C, and C depends on > both D and E. > > If you recursively remove from C, by far the simplest thing to do is to > remove all the things that depend on it (and so on until you hit leaf > packages). But it's not just simple, it's also a useful thing to do: "I > want to get package C off my system, so do what it takes to make that > happen." > > If you recurse in the other direction, though (assume for the moment that A > and B are no longer installed, so that C is a leaf package), then after you > remove C, you have a decision to make -- now that D and E are both leaf > packages, both could be removed as far as the package graph is concerned, > since nothing depends on them. > > But what if the user had explicitly asked to place E on the system -- that > is, they'd done "pkg install E" followed by "pkg install C" at some later > point. It would be rude to remove E, as they might not know that a > recursive removal of C would do so, and they haven't expressed an explicit > interest in having E removed. This is "user intent".
If I say 'pkg uninstall C', I mean uninstall that one package and nothing more. Likewise if I want to uninstall D or E. Am I breaking a package graph, probably. In that case, let pkg tell me that I'm potentially breaking whatever package depends on what I'm removing and allow me to change my mind or move on and remove the package. I may even then want to remove the packages that depend on the one I was going to remove now that I know about them. Now if I say 'pkg uninstall -r C', I mean uninstall C and any other packages that are installed as dependencies of C. Ideally, if any of the dependent packages are required by something other than C I'd like to keep them installed until those other leaf packages are uninstalled. Going the other direction, if I want to uninstall D then I'd expect the pkg system to warn me that I'm going to potentially break whatever leaf packages depend on D. Uninstalling D with -r doesn't make a lot of sense to me. I don't see working in that direction (backwards). If I were doing that I'd be saying remove D and follow the chain back to the packages that depend on it which leads to C and then where do you go? Following back to A and B doesn't seem right to me. I think recursive uninstall should work 'top-down' and not 'bottom-up'. To get to your scenario about someone explicitly adding D then C in two separate operations, I might not want to remove D if I recursively uninstall C that's true. Then again, I very well might. I could very well think I'm smarter than the packaging system and know that C requires D and so thought I'd 'be clever' and install D first then C. But I only installed D to satisfy C's dependency and so if C goes, so should D. Do we have any mechanism to track what packages were installed as a dependancy vs separately? For instance if C requires D and D is already installed when I install C, then if I remove C (recursively) then D stays installed because I (the user) explicitly installed D (or it's installed as a dependency for some other package). However, if D isn't already installed when I install C and it's only being installed because it's required by C then it comes out with C (unless I've installed some other package that requires D). Cheers, -- Glenn _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
