(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 <[email protected]>:
> On 2016-05-18 01:26:45 +0100, Manuel A. Fernandez Montecelo wrote:
>> 2016-05-17 3:15 GMT+01:00 Vincent Lefevre <[email protected]>:
>> > 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 <[email protected]>
_______________________________________________
Aptitude-devel mailing list
[email protected]
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/aptitude-devel
