Re: Source of Debian wisdom
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 |
Reply to: