Re: Pinning libstdc++6 does not work ...
On Wed, Oct 04, 2006 at 20:12:34 +0200, Stefan Bellon wrote:
> Florian Kulzer wrote:
> > On Wed, Oct 04, 2006 at 12:44:10 +0200, Stefan Bellon wrote:
> > > I have put the following in /etc/apt/preferences:
> > >
> > > Package: libstdc++6
> > > Pin: version 4.1.1-11
> > > Pin-Priority: 1001
> > >
> > > But then, when trying to do an update from within aptitude, it still
> > > wants to replace this libstdc++6 version with a later one.
> > If this does not work then you should post the output of
> > apt-cache policy libstdc++6
> > so that we can see how your apt rates the different versions of the
> > package.
> This results in the following output:
> bellonsn@cube$ apt-cache policy libstdc++6
> Installed: 4.1.1-11
> Candidate: 4.1.1-11
> Package pin: 4.1.1-11
> Version table:
> 4.1.1-15 1001
> 500 http://ftp.debian.org unstable/main Packages
> *** 4.1.1-11 1001
> 100 /var/lib/dpkg/status
> Why is the version 4.1.1-15 at priority 1001 as well? It looks to me
> like this is the problem.
I think that is normal; I have not used pinning in a while, though
(since moving to aptitude completely). The only important part is the
line "Package pin: 4.1.1-11" which means that apt has accepted your
preferences file and pinned the package to the specified version. I am
starting to suspect that pinning such an important library to an
obsolete version might simply confuse apt(itude)'s update logic beyond
> > > "hold" libstdc++6 in aptitude, I get over 50 broken packages and
> > > cannot resolve them manually.
> > If your system is in a consistent state then it should be possible to
> > put the library on hold without breaking other packages. This hold
> > will of course block upgrades of all dependent packages. This can
> > become awkward pretty soon since libstdc++6 is an important library.
> The system was in consistent state the last time I updated it (which
> admittedly is now some time ago because of said issue).
> > > What's the way to go if I want to pin libstdc++6 4.1.1-11 and all
> > > dependent packages, but being able to update other packages?
> > I think the following should work: Run "aptitude keep-all" to cancel
> > all scheduled actions. Start aptitude in interactive mode; there
> > should be no broken packages. (Check with 'b'; if there are broken
> > packages you have to fix them first.) Put libstdc++6 on hold. If you
> > now use 'U' to request an upgrade then aptitude should detect the
> > problems with the new versions of the packages that depend on
> > libstdc++6. It should propose different ways of resolving the
> > conflicts; one of them should be 'suggests 50+x keeps'. If you accept
> > that resolution then aptitude should be able to upgrade all packages
> > which are not affected by libstdc++6. (Use ',' and '.' to view the
> > different proposals and '!' to accept the best one.)
> While this approach seems to be the theoretically best one, it is
> practically impossible ... after pressing 'U' I have 59 broken
> packages. I have now skipped through the suggestions using "fast
> forward", i.e. holding down '.' and I am at suggestion 2500 right now.
> The "keeps" start at around 9 or 10 with lots of "removes" and then the
> "keeps" start to increase, however even at suggestion 2500 I'm still at
> only 42 "keeps".
> Is there a more practical solution?
OK, I propose plan B:
aptitude search -F "%p" '~U~b' | aptitude hold $(cat)
The first command should produce a list of all upgradable but broken
packages and the second one should put them all on hold. Maybe that will
The magic incantation to undo all this (once the library trouble is
sorted out) should be something like:
aptitude search -F "%p" '~ahold' | aptitude install $(cat)