The man page for dnf5 states: --repo=REPO_ID,... Enable just specified repositories. This is a list option which can be specified multiple times. Accepted values are ids, or a glob of ids. However the result of e.g. 'dnf5 list --repo=<repo-id>' includes a long list of packages *in addition* to those in the specified repo. The command needs the additional option '--available' to get the desired behaviour. Reproducible: Always Steps to Reproduce: 1.dnf5 list --repo=<repo-id> 2. 3. Actual Results: Long list of packages, not restricted to the specified repo. Expected Results: List of only those packages in the specified repo. Additional Information: Only the 'list' subcommand has been tested, but similar behaviour may be present with other dnf subcommands.
The list command by default shows two sets of packages: installed (printed in green) and available packages. When you specify the --repo option you limit the available packages to packages just from that repo but the installed package remain in full. I believe the docs are accurate, the --repo option doesn't control whether installed or available packages are considered. It is not possible to do --repo @system.
(In reply to amatej from comment #1) > The list command by default shows two sets of packages: installed (printed > in green) and available packages. > When you specify the --repo option you limit the available packages to > packages just from that repo but the installed package remain in full. > > I believe the docs are accurate, the --repo option doesn't control whether > installed or available packages are considered. It is not possible to do > --repo @system. I think this is counter-intuitive. Perhaps the solution is to modify the documentation, say by adding another example. It's also unclear what is meant by "available". Installed packages are in most cases available unless removed from the repo, but are excluded from the list when the '--available' option is used. The docs should specify that "available" means "available but not currently installed".
(In reply to Patrick O'Callaghan from comment #2) > (In reply to amatej from comment #1) > > The list command by default shows two sets of packages: installed (printed > > in green) and available packages. > > When you specify the --repo option you limit the available packages to > > packages just from that repo but the installed package remain in full. > > > > I believe the docs are accurate, the --repo option doesn't control whether > > installed or available packages are considered. It is not possible to do > > --repo @system. > > I think this is counter-intuitive. Perhaps the solution is to modify the > documentation, say by adding another example. > > It's also unclear what is meant by "available". Installed packages are in > most cases available unless removed from the repo, but are excluded from the > list when the '--available' option is used. The docs should specify that > "available" means "available but not currently installed". One more thing: the man page explicitly says: --repo=REPO_ID,... Enable just specified repositories. The obvious interpretation of that is that *only* the specified repos will be listed.
I think dnf5-list(8) manual could be better: It does not say what's the default behavior without any options. It does not say what happens when multiple options are used (union or intersection). It does not document that some options conflicts each other and trigger an error. It does not explain what "available" means. It does not explain what "recent" means. The manual has few examples whom one can deduce the behavior from. But a deduction is not a documentation. It still leave the reader in doubts. I think an explicit documentation is better. Regargind --repo option, that controlls what "avaiable" means. It's a global option hence not documented in every command. Though dnf5-list could mention it, especially when explaining the "available" predicate. Also the --help usage text could be better. E.g. if --installed List installed packages. was describe like this: --installed List only installed packages. The intersective behavior and exclusivity of some options would be less surprising and better implied.