On Mon, Jul 14, 2008 at 09:45:04AM -0500, Hugo Vanwoerkom <hvw59601@care2.com> was heard to say:
Daniel Burrows wrote:
This isn't present in sid any more, and according to
<http://bugs.debian.org/476781>, it's because it's an obsolete package.
I see a bunch of php5 stuff in the archive, maybe you need to upgrade to
that?
As I said before in a post, the reason for keeping php4-mysql around is
that WordPress behaves badly with the Textile 2cb plugin with php5-mysql.
I have 4 years of data in mysql with WP all using that plugin, so its
correct behavior if sortof important.
It may be obsolete, but its replacement causes problems for that plugin,
which is no longer supported BTW.
I would suggest that you look into your options for migrating off of
that plugin then -- you might be able to hold off upgrading for another
6 months or a year, but eventually something will happen (e.g., a major
security hole in php4) that makes staying with the
Of course, you probably know that already. :-)
In the meanwhile aptitude keeps insisting on removing that package no
matter what I pin preferences to :-(
Yes, pins just pick the version that "install" targets; they don't
affect the resolver's judgment. You might be able to get some help from
putting the package on hold; however, that just makes the resolver less
likely to remove it. Eventually the number of packages held back by
that one package will pile up to the point that it can't stand the
pressure any more and it decides to remove it. Hmm, if you don't mind
making it strict for all held packages, you could set
Aptitude::ProblemResolver::BreakHoldScore to an absurdly low value (say,
-100000). That would probably do the trick.
This is giving me an idea, though: it would probably be handy for
users if they could set scores and resolver hints (rejects/accepts) up
from the configuration file. Maybe I'll take a look at that when I have
some free time and stick it in the post-lenny branch. Unlike some
interesting ideas that I get, this one should be pretty trivial to
implement.