Re: Aptitude - Removing Unwanted Holds
Hi,
Thanks. It looks like you've solved my problem, and farthermore
provided guidance for avoding new problems of the same kind.
I apologize for troubling the list with what turned out to be an RTFM
question. I'm afraid I'm a bit of an old fogey - I do 'man <whatever>'
and 'man -k <whatever>', and if that provides anything, I assume
that's all there is, short of an explicit pointer elsewhere.
On Dec 04 2006, Florian Kulzer wrote:
> On Mon, Dec 04, 2006 at 11:57:54 -0800, Arlie Stephens wrote:
> > For some bizarre reason, aptitude seems extremely fond of holding
> > packages at prior versions. This has resulted in at least one csae of
> > my system being afflicted by a known - and fixed - bug.
[snip]
> > Second question - has anyone got any idea why it keeps hallucinating
> > holds I never requested? I suspect there's something bizarre about the
> > (company internal) package repository I'm using, and/or perhaps some
> > package I haven't noticed yet is doing something I don't want (perhaps
> > using other packaging tools), but I may be completely wrong.
>
> I think there is a slight misunderstanding here: Aptitude also lists
> packages as "held back" if they cannot be upgraded without further
> changes to the system, e.g. installing new dependencies, removing
> conflicting packages, etc. (It is normal for this to happen in Testing
> and Unstable.)
Ah, so held _doesn't_ necessarily imply what I thought it did,
"guided" primarily by the GUI.
> The procedure you describe above is (roughly) a manual way to implement
> the command "aptitude upgrade" in curses GUI. What you seem to want,
> however, is "aptitude dist-upgrade". Start aptitude in interactive mode,
> press 'U' (the SHIFT key makes the difference) followed by 'g' twice and
> you should see some serious action. 'U' will tell aptitude that you want
> to upgrade as many packages as possible. There can still be stuck
> packages, for example if the newer versions of some dependencies are
> still missing in the repository. Aptitude will propose different ways to
> address such problems. You can scroll through aptitude's proposals with
> ',' and '.' and accept one with '!'. In most cases the first proposal
> will be to keep a few packages at their presently installed versions and
> you should just accept that one. If you upgrade again in a few days you
> will usually find that this kind of problem has solved itself (because
> the missing pieces have meanwhile come to your mirror).
Aha. That would be the problem - not knowing the difefrence between
upgrade and dist-upgrade.
What I don't understand is when 'upgrade' would ever be useful. It
seems as if an awful lot of apps are, efefctively, released as
multiple packages, and an upgrade to one almost almost necessitates
upgrades of all its friends. An example would be the various bits of
kde. What I think I'm seeing is that if a set of new versions are
interdependent, upgrade won't touch them, even if all the various
pieces are already on my system in their prior versions.
> P.S. If you want to know which packages have really been placed on hold
> (as opposed to just being held back because of dependency issues)
> you can run
>
> aptitude search '~ahold'
>
> or use '~ahold' (without the single quotes) with the "search"
> (press '/') or "limit view" (press 'l') functions of the
> interactive interface.
>
> P.P.S. The aptitude-doc-en package is highly recommended for further
> reading.
--
Arlie
(Arlie Stephens arlie@worldash.org)
Reply to: