Score:4

Why would installed packages have status "Remove"?

cn flag

While doing other maintenance tasks I noticed that dpkg -l listed about 90 packages with status ri instead of expected ii.

I maintain packages solely with apt and aptitude and I haven't forced any packages but I regulary do apt install --no-install-recommends ... to avoid getting unneeded packages. I also try to carefully maintain the "automatically installed" flags and I have 2914 packages with status "automatically installed" (aptitude search '~i~M') and 422 packages with status "manually installed" (aptitude search '~i!~M').

What could be the reason for packages to have status Remove + Inst (ri) in dpkg -l listing when I haven't requested those packages to be removed? It seemed that the packages with this status were packages that I actually want to keep in the system. Could e.g. sudo apt dist-upgrade cause this without me noticing?

(I know that I can reinstall those packages with apt install --reinstall package-name to get status back to ii. I also often purge removed packages and aptitude search '~c' lists no packages.)

Additional details from another system with the same issue:

$ sudo apt dist-upgrade && sudo apt autoremove && dpkg -l | grep ^ri | wc -l
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Calculating upgrade... Done
The following packages have been kept back:
  virtualbox-6.0
0 upgraded, 0 newly installed, 0 to remove and 1 not upgraded.
Reading package lists... Done
Building dependency tree       
Reading state information... Done
0 upgraded, 0 newly installed, 0 to remove and 3 not upgraded.
171

So dist-upgrade nor autoremove do not touch the 171 packages with ri status.

Example package with ri status:

$ dpkg -l ca-certificates-java
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name                                            Version                      Architecture                 Description
+++-===============================================-============================-============================-===================================================================================================
ri  ca-certificates-java                            20160321ubuntu1              all                          Common CA certificates (JKS keystore)

and additional info for the same package:

$ aptitude show ca-certificates-java
Package: ca-certificates-java            
State: installed
Automatically installed: no
Multi-Arch: foreign
Version: ...

$ aptitude why ca-certificates-java 
i   default-jre-headless   Depends openjdk-8-jre-headless
iBA openjdk-8-jre-headless Depends ca-certificates-java  

$ apt-mark showhold
virtualbox-6.0

Additional info after reading about possible causes:

As explained in answer https://askubuntu.com/a/802612/50254 the status of these packages can be fixed to match currently installed packages by running (note that the line feed after IFS is not a typo but this command requires setting IFS to single linefeed):

export IFS='
'
for i in $(dpkg -l |egrep '^[a-z]i.*' |awk '{print $2" install"}') ; do echo $i|dpkg --set-selections  ; done
unset IFS

The reason/cause for this problem is still unknown. The ri status is supposed to mean that dselect (old debian package manager nowadays completely replaced by apt) has used to mark package to be removed from the system and if you actually want to apply those selection states you can run apt-get dselect-upgrade. See man dpkg and section "INFORMATION ABOUT PACKAGES" for more information.

The apt install --reinstall package-name is also okay but it will do more than the minimum change to system to fix the problem.

Terrance avatar
id flag
I'm not 100% sure, but it sound to me that the packages marked with `ri` could have been a dependent of another package that was removed but they weren't removed as maybe the `--autoremove` switch for `apt` wasn't used. But I don't recommend using `--autoremove` as you may remove other needed packages. I wish that part of package management was perfect, but it's not. I have accidentally killed systems because an app set them all for autoremove.
cn flag
That was a good suggestion but it wasn't the cause. I added info how neither `dist-upgrade` nor `autoremove` do anything to these packages.
Terrance avatar
id flag
Hmmmmm, yeah, sorry, I am out of suggestions on this one. +1 and hopefully someone else has stumbled across this. Running `dpkg -l | grep -w "ri"` yields nothing on my system, but `dpkg -l | grep -w "rc"` does, but thats for config and a completely different scenario. I hope you find an answer!
Terrance avatar
id flag
I have been looking a little deeper into your situation and while I am really not finding any solid answers for what is actually causing this, maybe some clues to be able to remedy might be found in https://askubuntu.com/posts/1352232/edit , https://askubuntu.com/a/165961/231142 and https://askubuntu.com/a/166254/231142
cn flag
@Terrance: It seems that the packages marked `ri` match this list: `dpkg --get-selections | awk '$2 == "deinstall" {print $1}'`. So the question is what process could accidentally mark `deinstall` for `dselect` when I don't use `dselect` for anything?
Terrance avatar
id flag
Oops, I just realized that in my above comment the first link is one that was in my buffer. My bad. Let me see if I can find the correct link there. It had some decent info in it.
Terrance avatar
id flag
Unfortunately, I don't know what exactly is causing it. I guess you can look through the logs in `/var/log/dpkg.log` or maybe something like `journalctl -xe`. I really wish I was experiencing the same issue as it would really help to have a second pair of eyes. Another link that I did find was where the `--clear-selections` was ran and caused something similar. It is hard to say if this might have been ran either. https://askubuntu.com/questions/687272/revert-accidental-dpkg-clear-selections?rq=1
cn flag
Yeah, I did read about `dpkg --clear-selections`, too, but I definitely haven't run that. And *I'll not run that after reading what it does*. I did also find that `deinstall` is historically used to signal `dpkg` by `dselect` that a package should be removed. However, I just checked and I don't even have `dselect` installed so that shouldn't be setting incorrect flags. Very interesting problem indeed. My current guess would be that VirtualBox package has executed some wrong commands because both these systems have VirtualBox installed and this problem seems to be pretty rare in general.
cn flag
I also checked `journalctl` and it doesn't mention the problematic package during the last 1.5 years I've logs available. The system was installed about 11 months earlier so the error must have happened at that time or whatever causes this doesn't not log to `journalctl` at all.
Score:2
de flag

disclaimer: i'm not a pro when it comes to distributions, so these are just my guesses by putting 1 and 1 multiple times together.

prologue

on an older Ubuntu machine i have one package with status ri, which is libllvm5.0 (and a bunch of other normal ii-packages like libllvm4.0 and libllvm6.0). the packages <= libllvm5.0 are marked as manually installed but libllvm6.0 is marked as automatically installed.
so my guess would be, that it was a dependency and got obsolete ether by upgrading or removing the dependent package.

explanation

going through your arguments/conditions one by one:

  • i only use --no-install-recommends:
    well, needed dependencies are installed nevertheless, else the program wouldn't work.
  • autoremove does nothing to these packages:
    well, kind of... i'm pretty sure all the ri-packages left alone by autoremove are marked as manually installed, although you have never installed it "separately". this is because after an initial setup a very few (if any?) packages are marked as automatically installed due to the fact that it isn't really possible to determine what packages you would have installed intentionally because this would vary from user to user. (so... a kind of "you have manually installed your OS".)
  • could sudo apt dist-upgrade cause this?:
    no and yes... sudo apt dist-upgrade on itself does not cause this, but with upgrading the whole system it is much more likely, that a bunch of (initially installed) packages will get obsolete.

to wrap up THE REASON: my guess would be that that these packages were installed by the initial setup, therefore marked as manually installed and then got obsolete by upgrading some packages or the whole distribution. and because they are marked as manually installed, they aren't touched by autoremove.

cn flag
This sounds reasonable explanation. All the packages having status `ri` also have status `Automatically installed: no` when queried with `aptitude show packagename`. However, I'd expect *all* manually installed packages to always stay in `ii` status instead of getting marked for removal with `ri` status.
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.