Hey.

I've seen the following already few times, but always used apt via aptitude,
so maybe the problem is actually within that.

What happens is the following:
- I upgrade/install/remove a number of packages.
- Amongt one/several of them there is an error during installation and one
  gets a line like:
  Errors were encountered while processing:
  packagename1
  packagename2
  ...
- At the point, /var/log/apt/term.log ends with the ususal:
  Log ended: <date>

- However, aptitude seems to retry once...
  Sometimes this means that all packages that haven't been installed/upgraded/
  removed, get now done, that is: *before* the errorneous package from above
  gets tried again.
  This means that all their log output is lost.
  Sometimes the packages that failed previously actually run through fine the
  2nd time.
  So again, that output would be lost.


Cheers,
Chris.

A quick look at the code (src/generic/apt/download_install_manager.cc)
suggests aptitude runs 'dpkg --configure -a' explicitly if libapt reports
encountering a failure and as such completely runs outside the control
of libapt and its logging (among many other things).

A quick git blame isn't very conclusive on why that is done, just that
it seems to be done for at least 10 years.

I am not sure if its a good idea to run that always unconditionally, but
then it is likely what a user runs unconditionally manually anyway, and
not much different to what happens if you run things like 'apt install
--fix-broken', as you either luck out or not so…

So perhaps we should indeed offer a way to do this a bit more automatic
for the user. I would first like to hear if the current aptitude devs
have any idea why that is run and their opinion on it though.

(This could be a reassign, but all they could do is removing the line
 in question or reassign it back to us as a feature wish, so lets skip
 the ping pong for now while thinking about this a bit longer)


Best regards

David Kalnischkies

Hi,

(I know that sometimes some of those who will read this put me in copy
hoping to get a reply from me about other bugs, but in the last couple
of years I cannot cope and my work in Debian is mostly restricted to the
riscv64 port, sorry.  I happened to see this by chance, so replying to
it).

2021-08-17 11:43 David Kalnischkies:

Actually, the oldest reference in git:

   commit db949f313eb10b747a875067623b89c47ee2b81d
   Author: Daniel Burrows <dburrows@debian.org>
   Date:   Sat Oct 1 23:40:49 2005 +0000

     [aptitude @ Import the Subversion repository into darcs.]

The oldest repos in SVN and (I think that other version-control-systems
for some period) are lost, I am afraid.

There's another comment in this commit, although it doesn't really shed
much light into it, just that it's somehow needed:

   commit 9e3f959f55bb500f82f690df2e66be052d8e0ae0
   Author: Daniel Burrows <Daniel_Burrows@alumni.brown.edu>
   Date:   Sun Apr 22 16:12:45 2007 +0000

     [aptitude @ Add DPKG_NO_TSTP to the environment when configuring packages after something failed to install. (Closes: #367052)]
     Apparently this is necessary to keep things sane.  It would be nice if I
     could call on apt to do this, but apt doesn't expose a wrapper around
     "dpkg --configure -a".

There are other more recent changes touching this line, but most are not
very relevant or don't add anything new to the reasons why this is
needed.

In 2016 I made another change:

   commit e8f0ba7f42e784d4a3886904d1425b642b7d7433
   Author: Manuel A. Fernandez Montecelo <manuel.montezelo@gmail.com>
   Date:   Thu Mar 3 00:52:30 2016 +0000

     Fix problem with recent change that prevented to work with local repositories (Closes: #816537)

     Even if we would like to not have to get locks and have to call
     fetcher->Run() if no (remote) fetch is needed (see #766122), it is needed
     anyway to work with local repositories (see #816537).

In which, for some reason that I cannot explain, included this change:

          case pkgPackageManager::Failed:
          _error->DumpErrors();
   -      cerr << _("Failed to perform requested operation on package.  Trying to recover:") << endl;
   +      //cout << _("Failed to perform requested operation on package.  Trying to recover:") << endl;
          if(system("DPKG_NO_TSTP=1 dpkg --configure -a") != 0) { /* ignore */ }
          break;

So presumably at that point, 5 years ago, at least printed a message,
but I am not sure if I committed the above as a mistake when doing other
changes to the same file, or what was the reason for that.

aptitude always wanted to be more helpful/opinionated than apt and so
more aggressive with doing these kind of changes without asking, and
perhaps at the time that this was implemented the breakages were
occurring more often and asking was annoying.

As you say, I think that running "dpkg --configure -a" or an equivalent
is the only reasonable thing to do at that point, either automatically
from a tool or asking the user to do it.

Maybe it is a good idea to run first "apt install --fix-broken" to get
it logged in apt's logs, and defauling to "dpkg --configure -a" as last
resort.

And perhaps also asking confirmation about this to the user, or at least
restoring the message warning about this.

So I think that this is only relevant for apt if you want to create what
the author was hoping for at the time, copying from the commit message
above:

     Apparently this is necessary to keep things sane.  It would be nice if I
     could call on apt to do this, but apt doesn't expose a wrapper around
     "dpkg --configure -a".

And if you don't think that it's a good idea, then probably better to
reassign to aptitude, to do the changes above.  But from my side, I
don't have time to implement them any time soon...


Cheers.