Should I manually install "held back" packages

General Linux Question
,
1

When I run Ubuntu updates I frequently see the message “The following packages have been held back:” and a list of names. My understanding, possibly wrong, is that they’ve been held back because they either need to be installed after some other package or that they might not be compatible with something I’ve got installed on my system.

I did a couple of searches on the topic and got conflicting answers. On one side I found instructions about how to install the held back packages and on the other the advice “Don’t ever manually install held back packages—wait for the OS to decide when they go in.”

A specific example: today the package ‘tzdata’ is being held back. I can’t see that there’d be any harm in updating time-zone info now versus closer to the end of daylight saving time but I could be wrong.

Advice? Opinions?

2

It depends.

Find out what the reason for holding back is and then judge based on that if you should still upgrade or not.

1 Like
3

If you have any suggestions about how to identify the reason a package was held back please let me know. I haven’t been able to find out how to do this.

1 Like
4

There is a recent It’s Foss article on this: https://itsfoss.com/following-packages-have-been-kept-back/

Normally, when you run the sudo apt update and sudo apt upgrade commands, it updates all the installed packages to their available newer versions.

However, if the dependencies of an installed package have been changed such that it requires installation of new packages, the installed package won’t be upgraded with the system update and you’ll see package kept back error.

1 Like
5

https://kubuntu-users.narkive.com/mqtH6tJg/why-are-packages-being-held-back

https://forums.debian.net/viewtopic.php?t=25215

https://debian-user.debian.narkive.com/9lVK9ioy/why-are-so-many-packages-held-back

6

I’m going to try a little experiment: I’m going to NOT install the held back packages for a while and see if, eventually, the OS gets things arranged so that those packages get automatically installed.

7

Starting roughly with Ubuntu 21.04 they expanded using “phased in packages” Packages are slowly released to the community to make sure there are no conflicts. To check to see if that is the reason you can run the command apt-cache policy [packagename] of one of the kept back packages you have. Look for the “phased” percentage. It’s only present if the package is being phased in. If that is the reason it will usually install in a few days without you having to do anything.

1 Like
8

Can someone explain the difference between this and rolling release?
It seems the same to me.

9

So, everyone is forced to be a Guinea Pig Beta User and risk having to end up with a non-working PC one morning. Great.

Actually, it would be:

apt policy packagename

So, we could do something like the following.

#!/bin/bash

grep -q 'phased' <<<"$(sudo apt policy "$1")" && \
echo "Package is phased." || \
echo "Package is not phased."

This could be put into a script or we could create a temporary function, instead.

function isPackagePhased {
  grep -q 'phased' <<<"$(sudo apt policy "$1")" && \
  echo "Package is phased." || \
  echo "Package is not phased."
}

And use it like this.

isPackagePhased "tmux"
10
11

I told you Ubuntu was going off the rails.
It might be a good move to hop off before they crash

12
13

It’s still better than the alternatives. At least Ubuntu works to some degree, compared to its Linux GUI alternatives. The vast majority of alternatives cannot even get the most basic shit right. It’s worse than talking to a mental patient.

14

All this is based on what I found when i was looking into the kept back packages. I am by no means an expert when it comes to Linux.

1 Like
15

I dont hear the same problems in Debian or Devuan. They seem to test their packages before release.
Its all about quality and dedication of the people managing a distro.

16

No. Debian just uses extremely old packages. That’s it. The “stable” edition of Debian is basically already really old in the real world. The “testing” edition is much better, but the more you go into that direction, the more unstable it becomes, as well. So, no real differences there.

17

I disagree with Akito about us being forced to be beta testers. I see it as Ubuntu being cautious. There is no possible way to foresee every combination of hardware, software, preferences, settings, etc., that exist among users. Unforeseeable bad interactions are going to occur from time to time in a small percentage of computers.

Thank you for the info about the “apt policy” command and phased updates. Here’s this morning’s result:

don@don-X1-Carbon-5th ~ $ apt policy dmidecode
dmidecode:
Installed: 3.3-3
Candidate: 3.3-3ubuntu0.1
Version table:
3.3-3ubuntu0.1 500 (phased 40%)
500 Index of /ubuntu jammy-updates/main amd64 Packages
*** 3.3-3 500
500 Index of /ubuntu jammy/main amd64 Packages
100 /var/lib/dpkg/status

I will sit tight and let the update happen automatically.

18

That is correct. However, with proper, dedicated and professional testing you can mitigate most issues, especially the biggest, most glaring ones. If you have sophisticated tests like that, then you can without any issue release everything at once to all users, without experiencing serious trouble. There will always be bugs here & there, though the point of all this is mitigating the most glaring & biggest issues, like e.g. a bug that can wipe all your data or something.

Therefore, the problem is, that the tests, if there are any, are not good enough. There should obviously be more tests and their quality should increase much more.

You can use the example I provided.

19

Right.
Is there some reason not to use old packages that work in combination without problems.
New package versions only occasionally add something useful, most of it is gloss and fashion.

20

That gets back to staff and management. You need brains and dedication to put software together.