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:
On Tue, Aug 17, 2021 at 03:13:20AM +0200, Christoph Anton Mitterer wrote:
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:
- However, aptitude seems to retry once...
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.
Actually, the oldest reference in git:
commit db949f313eb10b747a875067623b89c47ee2b81d
Author: Daniel Burrows
Date: Sat Oct 1 23:40:49 2005 +
[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
Date: Sun Apr 22 16:12:45 2007 +
[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
Date: Thu Mar 3 00:52:30 2016 +
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.
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)
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:
