`dnf needs-restarting` | '-u' option declared as unknown

[Ricky-Tigg]

• tested on OS: Fedora; Rawhide branch
• dnf-plugins-core: v.: 4.10.1

Reference

NEEDS-RESTARTING(1) manual | Sep 19, 2025

NAME
 needs-restarting - redirecting to DNF needs-restarting Plugin

SYNOPSIS
 dnf needs-restarting [-u] [-r] [-s]

OPTIONS
 All general DNF options are accepted, see Options in dnf(8) for details.

Description

Hello. All options of that manual are valid for DNF v. 4 but not all are valid for DNF v. 5, which respectively currently matches dnf4 and dnf5.

For someone who is not part of the project, these are, at best, the changes that can be observed as having been introduced.

$ ls -l /usr/bin/dnf
[...] /usr/bin/dnf -> dnf5
$ ls -l /usr/bin/dnf4
[...] /usr/bin/dnf4 -> dnf-3

Changes that are now source of the following issues.

To reproduce

$ dnf needs-restarting -u
Unknown argument "-u" for command "needs-restarting". Add "--help" [...]

Since there could be multiple causes for this message, which anyway does indicate an issue, it is up to you, as the authors of these changes, to determine the cause.

man 8 dnf

Which changes also cause to no longer open the manual for DNF4(8) but instead DNF5(8) in which the above issue occurs.

[evan-goode]

There are two issues here:

1. DNF5 needs-restarting doesn't (yet) support all options supported by DNF4 needs-restarting. See needs-restarting should be able to list non-systemd processes that need restarting dnf5#1730, Please add --exclude-services to dnf needs-restarting dnf5#2342. Regardless, the DNF5 plugin is a new implementation with different behavior and shouldn't share a man page with the DNF4 plugin.
2. man needs-restarting points to the man page for needs-restarting from dnf-plugins-core. IMO it's strange that the bare DNF plugin names like needs-restarting are man page titles at all. We also have man dnf4-needs-restarting (correctly pointing to DNF4 docs) and man dnf-needs-restarting / man dnf5-needs-restarting (correctly pointing to DNF5 docs).

[Ricky-Tigg]

On Fedora, it can be observed that when a binary file being in /usr/bin is covered by a man-page file, the name related to that latter is named accordingly to the name of its related binary file. So does manual's synopsis and so may do manual's title.

dnf5 binary file

$ man -l /usr/share/man/man8/dnf5.8.gz
DNF5(8)                       dnf5                      DNF5(8)
[...]
SYNOPSIS
 dnf5 <command> [options] [<args>...]

$ rpm -ql dnf5 | grep -E "^/usr/bin/dnf5|dnf5.8.gz$"
/usr/bin/dnf5
/usr/share/man/man8/dnf5.8.gz

needs-restarting binary file

Observable in man -l /usr/share/man/man1/needs-restarting.1.gz

• non related title | "dnf-plugins-core" instead of "needs-restarting"
• erroneus synopsys | 'dnf needs-restarting [...]' instead of 'needs-restarting [...]'

$ rpm -qif `which needs-restarting` | grep -E '^Name|^Source'
Name: dnf-utils
Source RPM: dnf-plugins-core-4.10.1-[...]
$ rpm -ql dnf-utils | grep needs-restarting
/usr/bin/needs-restarting
/usr/share/man/man1/needs-restarting.1.gz

[evan-goode]

I see, I was not aware of these /usr/bin/needs-restarting symlinks.

Currently, DNF5 (via the package dnf5-plugins) does not provide /usr/bin/needs-restarting or any of those other plugin symlinks. If we want to have dnf5-plugins provide /usr/bin/needs-restarting and others, we would need to:

1. Create and package additional binaries or wrapper scripts to call DNF5 with the correct arguments, or create a dnf5-utils executable that switches off argv[0] like DNF4 does and use symlinks.
2. Have dnf-plugins-core stop providing the binaries so that DNF5 and DNF4 remain mutually installable. Swapping ownership of the single dnf binary was a headache enough...

In my opinion it's not worth doing this. We should deprecate these "shortcut" executables that crowd $PATH and prefer dnf needs-restarting, etc. Users have an easy workaround: alias needs-restarting='dnf needs-restarting'.

We can amend the DNF4 plugin man pages to make them more clear which version of DNF they are documenting.

[Ricky-Tigg]

For those who choose to support Fedora, and therefore indirectly IBM's Red Hat, currently pre-installed by default on all Fedora Server and Desktop editions are not one but three active binaries dedicated as command-line package managers that support RPM packages, modulemd modules, comps groups and environments, and this with a significant part of redundant features ans functionalities; RPM, DNF v. 4 and DNF v. 5, Yum having been deprecated by its developers, although despite this, it is still shipped in the Fedora Project's DNF5 package as a symbolic link.

$ ls -l /usr/bin/yum
[...] /usr/bin/yum -> dnf5

Hard to justify anymore its usefulness, not even in the sake of compatibility.

Can we reasonably predict that Red Hat/Fedora, in the distant future or not, will be able to reach maturity, or something very close to it, notably by demonstrating that its RPM packages can finally be maintained and managed by a single command-line package manager? This will be necessary in any case in order to allow the collective optimization of developers' efforts by focusing them from now on on a single component. When I think of all these vulnerabilities involving RPM, Yum, DNF v. 4, DNF v. 5, accumulated on this platform and bugzilla.redhat.com…