On Sun, Aug 19, 2007 at 22:06:29 +0000, s. keeling wrote: [...]
> For current stable/Etch, aptitude is recommended, but many still stick > with apt-get. > > The biggest problem I've noticed is "aptitude remove blah" where > "blah" is some KDE or Gnome app, tends to want to blow away > *everything* that's even remotely related to KDE or Gnome. I use > neither KDE or Gnome, so that's not a problem here. > > There are tricks you can use to avoid this sort of thing, but I've not > bothered to learn what they are. Perhaps others can help. The problem is this: If you install the "kde" (or "gnome") metapackage with aptitude then all the other KDE (Gnome) packages are marked as "automatically installed" because they were pulled in to satisfy the dependencies of the metapackage. (That is in fact the very purpose of these metapackages: To save you the trouble of installing all the parts of KDE/Gnome manually. With aptitude, this also gives you an easy way to remove all of KDE/Gnome again: Just remove the top-level metapackage and all the automatically installed dependencies will be uninstalled, too.) Now, as long as you keep the whole set of packages, everything is fine. However, as soon as you remove one component you will get a domino effect: Let's say you want to remove knewsticker. This means that the kdenetwork metapackage has to be removed, too, because it depends on knewsticker. Unfortunately this kills the kde metapackage (since it depends on kdenetwork) and the whole house of cards collapses. With the kde package scheduled for removal, all its automatically installed dependencies are "unused" (as fas as aptitude knows) and therefore aptitude will try to remove them all at the next opportunity. This gets you into the dreaded "288 packages will be removed, do you want to continue?" situation. The first thing to do in such a case is to run aptitude keep-all (or use "Actions -> Cancel pending actions" in interactive mode) to make aptitude forget all scheduled actions. (Watch out, if you used "hold" to block buggy packages then this information will be erased, too, I think.) Then you have to figure out what is going on. The output of "aptitude remove knewsticker" gives you a pretty good hint: ---------- [...] The following packages have unmet dependencies: kdenetwork: Depends: knewsticker (>= 4:3.5.7-4) but it is not installable Resolving dependencies... The following actions will resolve these dependencies: Remove the following packages: kde kdenetwork Score is 188 Accept this solution? [Y/n/q/?] q Abandoning all efforts to resolve these dependencies. Abort. ---------- (Note: If you abort aptitude like this then you do not even have to use the "keep-all/cancel pending actions" step.) Now you have to tell aptitude that the dependencies of the kde and kdenetwork metapackages should be regarded as manually installed: aptitude unmarkauto '~R^kde$' aptitude unmarkauto '~R^kdenetwork$' After that you can remove knewsticker and keep the rest of the system in place. The (empty) kdenetwork and kde metapackages still have to go, of course, so you will miss the convenience that they offer. You have to decide for yourself if being able to remove some component(s) is worth that. The whole thing should work the same for other metapackages (gnome, xorg, etc.) Just walk down the chain of dependencies with "unmarkauto" until you are able to perform your intended action without causing collateral damage. For more complicated cases it can be helpful to use aptitude in interactive mode because that gives you a quick way to follow chains of dependencies, in both "forward" and "reverse" direction. -- Regards, | http://users.icfo.es/Florian.Kulzer Florian | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
