On 2016-04-01 16:24:47 +0100, Manuel A. Fernandez Montecelo wrote:
> If you didn't have several versions enabled at the same time, libecm0
> would maybe be detected as "obsolete" and maybe then apt-get
> dist-ugprade would decide to go ahead with the upgrade and remove the
> obsolete package. But since your package is marked as manually
> installed, it probably does not try to remove it anyway, even if it
> was "obsolete".
After explicitly marking the package as auto:
i A libecm0 6.4.4+ds-5 6.4.4+ds-5
I have the same problem when I want to upgrade.
$ aptitude why gmp-ecm
i libecm0-dev Depends libecm0 (= 6.4.4+ds-5)
i A libecm0 Recommends gmp-ecm (= 6.4.4+ds-5)
Well, that's libecm0-dev which is manually installed, but there
isn't much choice. The intent of an upgrade would be to replace
it by libecm1-dev.
When I type 'U' in the aptitude UI, I get:
idA gmp-ecm -186 kB 6.4.4+ds-5 7.0+ds-1
The first time, when I typed 'g', there was some other broken package
(due to the fact that libdconf-dbg no longer exists, thus not related
to gmp-ecm), and aptitude automatically undeleted gmp-ecm, which was
fine but but user could wonder why aptitude behaved inconsistently.
After resolving the issue with libdconf-dbg (basically removing it
and upgrading the *dconf* packages), when I type 'g', aptitude no
longer undeletes gmp-ecm, so that the Recommends is silently broken.
I also wonder what you mean by "several versions enabled at the same
time" above. If you mean several releases in /etc/apt/sources.list,
the non-default ones are just there to be able to install alternate
versions on *explicit* request; anyway, if aptitude chose to remove
gmp-ecm because it considered the old version as obsolete, then
there's no reason to do differently with libecm0-dev. Anyway, I've
tried after keeping only the unstable lines in sources.list then
"apt-get update", and aptitude had the same behavior, both with the
UI and with the command line:
# aptitude upgrade -s
The following packages will be REMOVED:
gmp-ecm{u}
0 packages upgraded, 0 newly installed, 1 to remove and 14 not upgraded.
Need to get 0 B of archives. After unpacking 186 kB will be freed.
Note: Using 'Simulate' mode.
Do you want to continue? [Y/n/?]
Would download/install/remove packages.
Also, note that I still have:
Aptitude::ProblemResolver::SolutionCost "safety, removals";
which would be a reason not to remove any package except auto
packages with no reverse dependency.
> What aptitude was doing until recently when requesting to upgrade
> gmp-ecm was to upgrade it and unmark it as auto (because otherwise it
> would be removed, as it happens now). It was one of the sources of
> the "silently looses auto flags", it seems.
>
> So there are 3 possibilities: old behaviour (upgrade, ignore broken
> recommends and set no-auto), current behaviour (upgrade ignoring
> broken recommends but preserve auto, which in this case results in
> removal because of "unused"), silently ignoring the upgrade request,
> emitting an error, or invoking the resolver.
I don't understand why this is all complicated. Since aptitude
already knows how not to break strong dependencies ("Depends"),
why can't it do exactly the same for "Recommends" when
APT::AutoRemove::RecommendsImportant is in effect?
--
Vincent Lefèvre <vinc...@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
