[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: howto find out why dist-upgrade wants to remove a package?



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.

  Daniel


Reply to: