Re: Interactive package management via aptitude

[Osamu Aoki <osamu@debian.org>]

Hi,

On Tue, Apr 09, 2013 at 09:32:52AM +0800, Chow Loong Jin wrote:
> On 09/04/2013 06:43, Adam Borowski wrote:
> > On Tue, Apr 09, 2013 at 04:19:19AM +0800, Chow Loong Jin wrote:
> >> Actually, in the event of aptitude not being able to resolve the dependencies
> >> satisfactorily the first round (from aptitude install foo), aptitude allows you
> >> to interactively pick other solutions, or tell it what to do:
> > 
> > Have you been able to get that effect from aptitude?  It seems that
> > whenever it sees some trouble (sometimes even when plain apt-get would
> > succeed), it proposes to remove the world, install a few unrelated
> > packages, and not do whatever you requested it to.  After declining a
> > varying number of such "solutions", it gives up even if it would take a
> > single action to resolve the problem.
> 
> Yeah, I have actually. It's just that the recent multiarch issues (which still
> haven't been fixed) tend to lead to aptitude attempting to remove the whole
> (foreign-arch) world. If none of the other decisions make sense, you're actually
> able to prod aptitude in the right direction by supplying some extra operations
> interactively at the [Y|n|q] prompt.
> 
> > I'm not sure if it makes sense to recommend aptitude in its present state.
> 
> I wouldn't recommend it when operating with multiarch enabled. Otherwise it's
> mostly fine.

Yes but it is not that bad. I was also shocked to see:
 * denial of downgrade request as the first suggestion
 * massive package removal as the second suggestion

I will be very careful when managing multiarch package with some strict
version dependency aptitude.  It seems we need to mark both archs
simultaneously when we do not-so-common thing such as downgrade.

(Also some version selection result seems not to be updated in display
but effective internally.  I still do not understand what aptitude is
doing ...  vey strange)

It was libboost causing bug for the last release and this time multiarch.

So we should keep this text this time again.

Osamu