[Aptitude-devel] Bug#825707: aptitude: should not regard a package as removed when another package has a Provides on it

Wed Jun 1 09:45:08 UTC 2016

2016-06-01 08:18 Vincent Lefevre:
>On 2016-05-31 19:12:40 +0100, Manuel A. Fernandez Montecelo wrote:
>> 2016-05-29 01:46 Vincent Lefevre:
>> > In the gnuplot5-data upgrade, one has:
>> >
>> > Package: gnuplot5-data
>> > Source: gnuplot5
>> > Version: 5.0.3+dfsg2-1
>> > Depends: aglfn, gnuplot-tex
>>
>> I see a discrepancy in the data (as of today, maybe it changed since you
>> reported it).
>>
>> The package which depends on gnuplot-text is "gnuplot-data", not
>> "gnuplot5-data".  "gnuplot5-data" does depend on aglfn, but not on
>> gnuplot-tex -- instead it *provides* the latter, as noted here:
>
>5.0.3+dfsg2-1 was the previous version in unstable. It is no longer
>available. But you can still see the dependency in the stable version:
>
>Package: gnuplot5-data
>Source: gnuplot5
>Version: 5.0.0~rc+dfsg2-1
>Depends: aglfn, gnuplot-tex
>
>So, expect a problem with an upgrade from the current stable to the
>next one.

According to the log I had upgraded yesterday from the relevant
versions:

  ------
  Tue, May 31 2016 15:07:48 +0100
  ...
  [REMOVE, NOT USED] gnuplot-tex:amd64 4.6.6-3
  ...
  [UPGRADE] gnuplot5-data:amd64 5.0.3+dfsg2-1 -> 5.0.3+dfsg2-2
  ------

The upgrade went without conflicts in my case.

>> > Unfortunately, when I try an upgrade, gnuplot-tex is regarded as
>> > removed (the real package is removed, but due to the Provides,
>> > the package should still be regarded as being present).
>> >
>> > At least "aptitude safe-upgrade", "aptitude full-upgrade", and "U"
>> > in the UI are affected, i.e. aptitude proposes to keep gnuplot5-data
>> > as the default choice.
>> >
>> > Moreover, even with the solution where gnuplot-tex is removed,
>> > aptitude does not say that it is provided by gnuplot5-data, so
>> > that one has the impression that something is lost.
>>
>> The description above is a bit vague.
>>
>> If the only thing by why you deduce that aptitude considers
>> "gnuplot-text" removed is because the first proposal of aptitude is to
>> "keep" it, perhaps it's not because of the fact that it would be removed
>> but by the fact that it conflicts with itself, and in the face of a
>> conflict maybe the "Keep" solution given just scores higher than other
>> solutions.
>
>Perhaps, but since a Breaks with itself is regarded as correct by
>the Debian Policy Manual (see above) and that this "does not count
>as a real breakage", this would be an even more important bug.

Not really.

As I said in the previous message, aptitude shows many bits of
information in the interface with many nuances.

In some part of the interface it can for example say that "gnuplot-tex"
is required by gnuplot5-data_5.0.3+dfsg2-1 (to explain the solution
suggesting to "keep gnuplot-text and gnuplot5-data_5.0.3+dfsg2-1 at
their current state/version" (both installed).

In other part of the interface it can say that "gnuplot-tex" is not
required (and therefore can be removed-unused, as in my log above)
because when considering the action to upgrade gnuplot5-data from
5.0.3+dfsg2-1 to -2, it is no longer required.

These behaviours are correct in principle, it's a matter of interpreting
them correctly in the context.

Some of them might be wrong or misleading, and those can be addressed,
but for that we'll need a more precise example of what's wrong.

>[...]
>> Also, I was able to upgrade a few days ago this set without being given
>> any conflict related to the gnuplot packages, but maybe it's because of
>> other differences related to config options and installed packages /
>> versions between your system and mine.
>
>Since gnuplot-tex has no other reverse dependencies, I doubt that
>this was due to other installed packages. Concerning the config
>options, I still have:
>
>Aptitude::ProblemResolver::SolutionCost "safety, removals";

Since you have gnuplot-tex and would be removed (due to either be
unused, or the latest gnuplot5-data breaking/replacing it), maybe the
"Keep" was offered before the "Upgrade" of the several related gnuplot
packages because of this reason -- you're asking to minimise removals,
even if they are obsolete/unused packages.

If the complaint is that in this specific case the removal shouldn't be
counted as such because in the "removals" cost because it transitions to
a virtual package with the same name... well, from many points of view a
removal will still happen (it's a real package being removed, after
all).  It's ambiguous[1] and a bit of a corner case, I don't think that
there's a strong reason to change.  Whether policy considers this a real
breakage or not, it doesn't have any bearing on the counting of
"removals" cost by aptitude.

In many situations "Keeps" are suggested as first option instead of
"Upgrades" also in the default resolver for different reasons and
depending on subtle score differences, it all depends on the concrete
situation as evaluated by the heuristic resolver.

[1] For example, if a "real" pkgA is removed but two packages providing
    pkgA are installed, should be counted as 1 removal, or as 1
    installation (2 installed minus 1 removed), or...?

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