Re: Pinning libstdc++6 does not work ...
Florian Kulzer wrote:
> On Wed, Oct 04, 2006 at 20:12:34 +0200, Stefan Bellon wrote:
> > This results in the following output:
> > bellonsn@cube$ apt-cache policy libstdc++6
> > 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
Wow, that's strange. I think you may be quite right, but I see no
excuse for that. Having an old Debian relase and mixing that with a
later release means using "obsolete" versions of important libraries as
well. If this is really the case, then I'd consider this a problem with
> 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 work.
When I did that, then libstdc++6 was not put on hold. So before I did
the above, I manually did
# aptitude hold libstdc++6
and then your suggestion. But afterwards there were still 28 broken
packages that could not be put on hold.
I think this may be the reason why apt's own pinning logic cannot
resolve the issue.
I'll go plan C then ... manually upgrading individual packages if it's
possible ... :-}
But thanks for all your help, I learnt a lot about apt's and aptitude's
command line usage.