[Aptitude-devel] Bug#819636: aptitude: wants to remove a recommended package

[Manuel A. Fernandez Montecelo]

Control: tags -1 + moreinfo


2016-04-01 0:29 GMT+01:00 Vincent Lefevre <vincent at vinc17.net>:
>> If the above is indeed what happens, the end result is not very useful
>> in this particular case; but from aptitude's POV if the user marks for
>> upgrade is because it doesn't want the current version of gpm-ecm.
>> Therefore, keeping the current version of gpm-ecm is not considered a
>> good option, and aptitude might break the recommends as a lesser evil
>
> This rather contradicts what David Kalnischkies says about Recommends
> in <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=489896#12>:
>
> "Recommends are installed by default by design as this is what the Debian
> policy requires.
>
> Not installing them (even while fixing up broken systems) means that we
> leave the system "slightly broken" as recommend packages should be
> installed… so, mot a bug, but by design."

Yes, that's true, as long as you don't have options set to the
contrary (that's what I was asking).

So not honouring them is the problem.

(There are some cases where the packages might be unavailable in a
given suite, due to wrong/obsolete dependencies or other cases.  I am
not sure what happens in that case, maybe the package is simply
uninstallable).


>> In particular, it seems that while you keep this package installed,
>> "apt-get dist-upgrade" will not allow you to upgrade gmp-ecm at all
>> until you remove libecm0, which doesn't sound very useful for the user
>> either if it indeed wants to ugprade that package.
>
> Note that I didn't say that I wanted to upgrade the package, but
> to upgrade the system.

aptitude doesn't differentiate (and probably it cannot, specially in
interactive mode) between "upgrading a package" and "upgrading the
system", or "upgrading packages matching a pattern".  Even if it can,
I don't think that it's useful to split hairs like this.


> Since libecm1 is the successor of libecm0,
> the right thing would have been to propose the upgrade to libecm1
> (ditto for the -dev package).

aptitude doesn't know if libecm1 is the successor of libecm0, if it's
compatible or it will break other packages which still depend on the
old library (as it's the case of many lib transitions with renaming
lib packages, as this case) or if it's just another package with a
similar name.  So it shouldn't propose it as an an upgrade.

In normal circumstances, users want to have packages installed
(gmp-ecm in this case) and libraries as pulled in as necessary, marked
as auto dependencies (yes, there are bugs in this area, but that's the
general idea).  When this package gets upgraded, new libs can get
pulled in automatically, and old/obsolete marked automatically get
removed.

That's the normal workflow that tools and maintainers follow, I don't
think that they are going to start adding dependencies between library
packages like that.


> BTW, what will happen with the next
> Debian/stable? Will the user be prevented from upgrading to the
> new gmp-ecm packages by "apt-get dist-upgrade"?

Since I don't use apt-get and apt-get dist-upgrade I don't know what's
the actual behaviour, but it seems to me that the same that it's
preventing you from upgrade now, it will probably prevent that in the
future.

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".


>> These kind of behaviours are particularly important for dist-upgrades
>> from stable to next stable, when many packages can be left behind as
>> obsolete packages (or local packages installed by the user from
>> elsewhere), and recommend non-existent packages in the new stable.
>
> I think that the right solution would be to warn the user before
> breaking Recommends. In any case, never break Recommends if this
> is not necessary.

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 am not sure what's the best behaviour yet, probably invoking the
full resolver is the best option.  The others, some might be
acceptable depending on the context, but probably not good overall.


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