6

On a freshly installed Fedora system, base packages such as sudo are not counted as user installed, i.e. dnf repoquery --userinstalled | grep sudo comes back empty. At the same time, these packages are also not considered by dnf autoremove, i.e. the command does not try to remove them. So far, so good.

Now, if I mark sudo as removable using dnf mark remove sudo, a subsequent dnf autoremove attempts (and fails) to remove it. The only way I know to again prevent autoremove to target sudo is to mark it as explicity user installed using dnf mark install sudo. However, now sudo has a different state than it had in the beginning: dnf repoquery --userinstalled | grep sudo now shows the sudo package.

My question is: How do I reset the state of a base package such as sudo? That is, how can I achieve that dnf repoquery --userinstalled | grep sudo comes back empty while dnf autoremove does not attempt to remove the package?

3
  • I don't think there's a way to do that yet. Your best bet is to not cause the situation in the first place. Apr 7, 2019 at 2:56
  • I see. What exactly is keeping base packages like sudo from being affected by autoremove in the first place? Is it some custom logic of dnf I could have a look at? If so, where?
    – inorik
    Apr 8, 2019 at 22:13
  • sudo is not an important enough package for such protection, but actual critical packages like dnf itself or systemd are protected. Try removing one of those and watch it refuse to do so. Apr 9, 2019 at 0:47

1 Answer 1

5

I think I found how it is supposed to work:

Packages can not only be marked as 'install' or 'remove' but also as 'group'. This seems to be the default state for packages that were installed using dnf group install. In the example above dnf mark group sudo restores the original state of the sudo package.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .