Draft: Introduce the idea of replaces/replaced by to important dep logic and UI

David Kalnischkiesrequested to merge
donkult/apt:wip/replaces into main

As mentioned on IRC the t64 transition prompted me to look into letting apt reason a bit about new and (maybe soon to be) removed packages, so that it can work with and display package renames (= t64 on 64bit archs) and soname bumps (= t64 elsewhere) differently to the rest.

For the important dep logic this mainly means that a previously unsatisfied important dep keeps being unsatisfied while we go from libfoo1 to libfoo1t64 (or, after the t64 to libfoo2) or from iceweasel to firefox.

Similarly for a user these changes are borderline ignoreable, but at the very least much less an issue compared to when apt decides to remove libfoo1 or worse iceweasel without a replacement, but they looked the same. If you wanted to check the t64 happenings you had to eyeball the NEW and REMOVE lists closely to not miss the real ones.

For this, I introduced a new list with the old title "The following new packages will completely REPLACE old packages" which shows "newname (replaces oldname)" for newname Conflicts/Breaks + Replaces + Provides oldname while newname is NEW and oldname REMOVE – newname/oldname are dropped from their usual listing, but still count as these actions in the summary.

That is a rather strict set of requirements, which many things that are quasi-replacements do not satisfy. Renames with a transitional package or soname bumps for example. For those, the (auto)remove entry is annotated with "oldname (replaced by newname)". The testcases contain an example of both:

The following packages were automatically installed and are no longer required:
  libsame1 (replaced by libsame2) oldrec
Use 'apt autoremove' to remove them.
The following new packages will completely REPLACE old packages:
  newname (replaces oldname)
The following NEW packages will be installed:
  libsame2 newrec
The following packages will be upgraded:
  instrec meta oldrec
3 upgraded, 3 newly installed, 1 to remove and 0 not upgraded.

Code wise that seems to work fine, but UI wise… in the new column world "newname (replaces oldname)" is not only rather large, but supposedly needs two colors on the individual package name, which is currently not supported by the column code as it colors the entire block, but this block is akin to a word-diff (if I accept the idea of the current coloring to be diff-based). Implementation wise compare removal of essentials and "libapt (due apt)". There is also something to be said about this displayed e.g. as "oldname => newname" instead, which I suppose might work in column, but as a wall not as much (and it of course highlights the oldname more).

The "replaced by" looks similar, but is different in that is is not part of the name in list logic, but of verbose (which previously existed only for version and forced a one-per-line). In -V mode it looks like this (different example):

The following packages were automatically installed and are no longer required:
   libbar1 (1, replaced by libbar2abiv5)
   libdasha1-1 (1, replaced by libdasha1-2000)

That is so because the "replaced by" feels like optional information, but at least for me more useful than the version number… so perhaps we should just go with -V as general verbose mode and have which information pieces that displays configurable – and the one-per-line a generic display mode akin to "wall-of-text" and column (or a setting to limit amount of columns?) existing now. And because we like configuration so much, that might be configured per list rather than for all of them.

Add to that, that I intend to work on an entirely different display style (one where the titles of the blocks are colored, rather than the block, so that individual package names can be colored if they match user-config apt-patterns – like being in section (old)libs, being manually-installed, shipped from experimental and the like) and this becomes one huge "What should ALL of it look like by default?" interdependent hot mess.

Both are btw in apt only as people could do strange things with parsing apt-get output, which only further complicates the UI matter. Anyway, suggests? Feedback if that seems reasonable as feature in general?

P.S.: Now that I have written this down, perhaps "replaced by" should be "obsoleted by" instead. Oh boy, decisions, decisions, decisions, …

Merge request reports