Score:0

How to make apt auto-upgrade packages even when a depends package is removed/renamed?

kh flag

Normal unattended-upgrades keeps back packages when a Depends package is removed/renamed. This is usually reasonable, but I would like to override this behavior, as it can lead to breakage which can be hard to detect/fix if it occurs in a cloud virtual machine that one isn't regularly interacting with. Is it possible to tell unattended-upgrades to not keep back such packages? (Note: I am not asking about phased upgrades.)

Specifically I had dotnet-runtime-7.0 auto-upgrade to a newer version while dotnet-hostfxr-7.0 was kept back due to one of its Depends being renamed. This broke dotnet and applications using the runtime as dotnet could no longer find the runtime (dotnet --list-runtimes returned nothing). While correcting this manually, I had the following output:

$ sudo apt upgrade aspnetcore-runtime-7.0
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
aspnetcore-runtime-7.0 is already the newest version (7.0.109-0ubuntu1~22.04.1).
Calculating upgrade... Done
The following packages have been kept back:
  dotnet-host dotnet-hostfxr-7.0
...
$ sudo apt upgrade dotnet-hostfxr-7.0
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Calculating upgrade... Done
The following packages will be REMOVED:
  dotnet-host
The following NEW packages will be installed:
  dotnet-host-7.0
The following packages will be upgraded:
  dotnet-hostfxr-7.0
1 upgraded, 1 newly installed, 1 to remove and 0 not upgraded.
1 standard LTS security update
Need to get 342 kB of archives.
...
user535733 avatar
cn flag
"*Normal apt auto-upgrade keeps back upgrades when a Depends package is removed/renamed.*" Well.... Apt uninstalls packages when their dependencies are removed. It "keeps back" upgrades only in the sense that the upgrade-able package is not installed at all. You cannot eat my lunchtime banana when my lunchbox contains only sandwiches. "Renaming" a dependency is similar to removing it. If apt depends upon Foo, then it wants Foo and nothing else.
guiverc avatar
cn flag
I don't really understand your issue, but re-packaging what annoys you to your own requirements seems to me the most logical answer (*given you appear to want different rules than the current packager(s)*)
Anton Tykhyy avatar
kh flag
Maybe I was not clear. I installed `dotnet-runtime-7.0` which depends on `dotnet-hostfxr-7.0` which depended on `dotnet-host`. Auto-upgrades installed upgrades to all these packages until the version of `dotnet-hostfxr-7.0` which stopped depending on `dotnet-host` and started depending on `dotnet-host-7.0` (thanks, MS). At that point `dotnet-host` and `dotnet-hostfxr-7.0` were kept back and no longer auto-upgraded.
muru avatar
us flag
What do you mean by "auto-upgraded"? `unattended-upgrades`? Anyway, if an update needs the installation or removal of a package, the commands to use would be `apt full-upgrade` or `apt-get dist-upgrade`.
Anton Tykhyy avatar
kh flag
Yes, probably unattended-upgrades. Can it be configured to install updates that need package removal, like the one in the example? I can't require people to run upgrades on my appliance VMs manually. I suppose I could run `apt full-upgrade` every day as a cron job, but it would be better to configure unattended-upgrades.
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.