[Aptitude-devel] Bug#823928: aptitude wants to remove manually installed packages with SolutionCost "safety, removals"

[Manuel A. Fernandez Montecelo]

(Discussing this is quite pointless anyway... but as a final message
from my side...)


2016-05-18 10:38 Vincent Lefevre:
>On 2016-05-18 10:04:50 +0100, Manuel A. Fernandez Montecelo wrote:
>> 2016-05-18 2:53 GMT+01:00 Vincent Lefevre <vincent at vinc17.net>:
>> > On 2016-05-18 01:26:45 +0100, Manuel A. Fernandez Montecelo wrote:
>> >> 2016-05-17 3:15 GMT+01:00 Vincent Lefevre <vincent at vinc17.net>:
>> >> > But note that I use SolutionCost "safety, removals", so that it should
>> >> > avoid packages from experimental or remove packages.
>> >>
>> >> aptitude never did that... and never will.
>> >
>> > I don't see why.
>>
>> Because aptitude also (or dare I say, *mostly*) caters for people who
>> want these solutions to be offered, and because I am not going to
>> spend time implementing solutions that complicate more the resolver
>> just to avoid those cases.
>
>People who want these solutions to be offered will obviously not use
>SolutionCost "safety, removals".

aptitude was never designed for the purpose that you described, in any
of its configurations.

If this doesn't match what users using those options want or expect,
that's too bad, but it's not going to change.  Perhaps they should do a
reality-check and adjust their expectations.


>> With approvals and rejects:
>>
>>   http://aptitude.alioth.debian.org/doc/en/ch02s03s03.html
>
>Perhaps this could work. But this is still annoying to have to reject
>removals manually.

aptitude, and using unstable and experimental in general, is for those
not afraid of getting their hands dirty.

Certainly, I'm not going to spend my time implementing and doing
something that I believe that it's wrong just to save you from
annoyances.

Besides, if you don't want to use the means that aptitude provides to
solve the situations that you complain about, well, up to you.  But
certainly, you're not getting any closer to get aptitude to behave in
the way that you want it to by continuously insisting on this.


>> Or marking all packages to keep (":") in the root of the Upgradable tree.
>
>But this prevents any upgrade.

Keep != Hold


>> If aptitude is asked to mark all upgradable packages to upgrade and
>> finds conflicts, it's quite natural than then it reports conflicts and
>> that you have to pick the upgrades one by one (or use the resolver
>> effectively).
>
>But what I seek is to resolve conflicts by keeping all the related
>packages at their current version.

This is quite easy to achieve with the resolver, as I explained in the
previous e-mail and many times before.  Many people do this successfully
every day with aptitude.


>> So I understand why you find it inconvenient/annoying, but aptitude
>> cannot magically fix things for you, specially since you using stable,
>> unstable and experimental at the same time, and multi-arch with out of
>> sync packages.
>
>Again, this is not magic. This is very easy to do manually (but
>tedious):
>
>  For each package proposed for upgrade:
>  1. Type '+'.
>  2. If there is any removal, cancel.
>  3. Otherwise, choose to upgrade.

Only that to upgrade, sometimes, packages left behind (e.g. in
transitions) have to be removed in order for the whole system to be
upgraded.  Otherwise the packages can get hold back indefinitely due to
old/local packages, and peculiarities of how Debian works.

People certainly don't want to hold back indefinetely the upgrade of 150
components of KDE just because an obsolete package is not removed.  And
even if they really don't want to upgrade KDE in that occasion, aptitude
should not fail to offer the (apparently) most sensible solution in that
case.

That's what it's expected to happen eventually in every system, it is
one of the most common situations that one takes when firing aptitude,
and basically what the shortcut "make all upgradable for upgrade" is
intended for.


Your reasonings about how "very easy" is to solve situations, in this
and in previous occasions, is often faulty and fails to account for
basic situations like this one.


>Everything that is possible to do manually with a predetermined
>decision should be possible to do automatically.

If only 1% of the things that I think that are possible would become
true "just like that"...


-- 
Manuel A. Fernandez Montecelo <manuel.montezelo at gmail.com>