On Fri, Aug 21, 2015 at 11:19:29PM +0200, Axel Beckert wrote: > I thought that apt considers itself essential and hence I'd rather > expected it to upgrade itself in favour of removing itself. Or does > the "fix mode" work differently with regards to this? It does, which is why you got the warning, but even essentials can't cross the candidate rule. I am guessing that you had apt/unstable installed on your machine, so an upgrade to apt/experimental would have meant changing from a 500 pin source to a 1 pin source… that isn't going to happen. The only real alternative is therefore to remove apt to complete the installation of libapt (as it breaks this apt verison). libapt-pkg5.0 is on the other hand installed from experimental without special nudges as it is available only in experimental and even a 1 pin source wins over nothing. The alternative is to remove aptitude, which is probably not what the user wants (packages usually don't end up in broken states because they can't be removed, but because the user wanted them installed, but something failed. The removal alternative is therefore likely not what the user wants). Of course, removing an essential package isn't a great idea, but the other option is just slightly less bad. > Aaaaand, I wonder (once again :-) if we should add a dependency from > aptitude to apt for the download methods which reside in the package > apt. Well, if you feel better I am going to add a 'Recommends: apt' to libapt. Depends is a bit harsh given that you can have multiple usecases without ever needing to download a file with apt (on this machine). There is the slight problem of having configuration set by apt which effects libapt, but that is an implementation detail and borderlining bug as we could just as well set it in libapt itself I guess. Depending on apt for that is too much through – there are again multiple usecases who work perfectly fine without the configs. Also, and that isn't unimportant, it makes installation order so much more difficult if we end up with a Breaks-Depends-Circle, which is why I would tend to avoid a depends on apt from aptitude as well – the situation is a bit esoteric if you don't happen to be running unstable or experimental and even then… On the other hand Recommends are practically free of charge and even through they don't provide much from an algorithm standpoint I think the main problem here is actually the user as there will always be situations in unstable in which resolvers will pick a "dumb" solution like removing themselves – and a dropped Recommends should nudge users in the right direction (= answering no). And the cherry on top of the icecream: I love the idea that even the aptitude maintainers recommend apt. SCNR. Best regards David Kalnischkies
Attachment:
signature.asc
Description: Digital signature