9

When I want to list installed packages, I do it usually in one of two ways.

The old fashioned way is using rpm -qa | grep <whatever I look for>, and that's that.

But recently I wanted a more comprehensive display of my packages, and henceforth, I used dnf list --installed <whatever I look for>.

However when looking at the result there are a couple things I don't understand.

Consider this example:

# dnf list --installed zsh                  
Last metadata expiration check: 0:13:25 ago on Mon Jul 11 05:48:04 2016.
Installed Packages
zsh.x86_64            5.2-5.fc24            @@commandline

(spaces in actual printout are wider)

So the resulting entries, are: «package» «version» «repo».

In my example that's:

  • package: zsh.x86_64
  • version: 5.2-5.fc24
  • repo: @@commandline

So far the resulting table is understandable, but I'm confused what the two '@@' mean in front of the repo name.

Also, "commandline" suggests the package was installed from command line (downloading the RPM, and then doing dnf install whatever.rpm in the command line, etc.). However I'm pretty sure I've installed zsh via dnf install zsh.

But that's not all.

I've several packages on my system installed from the repo @System, @fedora (however there's also fedora without the @) and things like @@commandline.

So what does that @ or @@ exactly mean in front of the repo name?

And how come I've got so many prominent packages installed from @@commandline although I'm more than sure I've installed them from the repos?

2

Let me throw a brick to attract some jade here.

dnf list all | less shows all packages(including installed and available packages). The output has two sections: "Installed Packages" and "Available Packages". All "Installed Packages" are preceded by @ sign, while "Available Packages" are not. So I believe @ signs show the packages are installed. If a package is installed but its original repo was deleted, I guess @@ sign is given.

dnf source code is hosted at https://github.com/rpm-software-management/dnf. After downloading the src code, do a grep commandline -ri . in the directory and it returns nothing. However, its github page does mention this,

It does package management using RPM, libsolv and hawkey libraries.

So I look at hawkey, which is hosted under same project, at https://github.com/rpm-software-management/hawkey. Looking at its code by grep -ri commandline ., it does show some results.

./src/types.h:#define HY_CMDLINE_REPO_NAME "@commandline"
./hawkey.spec:- fix: commandline RPMs do not provide their files (RhBug:1112810) (Ales Kozumplik)

So commandline comes from hawkey package. As to question why @comandline is shown in dnf list command, my wild guess is dnf code fails to use hawkey properly.

  • It seems the man page of dnf is incredibly silent about this. Suppose '@' denotes an installed package, does '@@' then mean it's manually installed from a non-repo source, perhaps? I'd really wish someone would clarify. – polemon Jul 12 '16 at 4:19
  • 1
    "Let me throw a brick to attract some jade here." ...I have absolutely no idea what that awesome and incomprehensible expression means, and I think I love it. 😍 "Idioms!" – FeRD Jun 29 at 19:27
1

(Disclaimer: I can't provide sources for any of this, because I've never seen any documentation which actually discusses these things. The information to follow is merely what I've been able to suss out through inspection, blackbox experimentation, haphazard trial-and-error, and plain old guesswork. Also, fair warning, it's overexpository to the point of being waaaay too long.)

DNF adds an @ to denote the repo an installed package was installed from, in dnf list context. As you noted:

I've several packages on my system installed from the repo @System, @fedora (however there's also fedora without the @) and things like @@commandline.

But in reality, you'll never see any package coming from fedora on the installed list, as every package there shows some @-repo as its source. (You can verify that by running sudo dnf list installed and inspecting; there are no repos listed without at least one @ sign.) When you view a package's information with dnf info, the "From repo:" field will show that repo name without the @. (So "From repo: fedora" is absolutely possible, and equivalent to @fedora in the installed list.)

But some repos are named with an @ sign at the front. As JohnKoch discovered in the hawkey sources, "@commandline" is defined as the "repo name" for "the commandline repo". So, @@commandline in the dnf list listing simply indicates an installed package From repo: @commandline, a repo which confusingly was given a name that starts with its own @-sign.

dnf info on any installed package will show Repository: @System, which is the other @-named virtual repo. It seems that @System is the virtual repo that holds the set of currently-installed packages, and @commandline the virtual source repo from whence a package came, when it did not come from any repo.

The meaning of @commandline and @System, and their relationship to each other, seems to have changed since I first wrote this answer. In some ways it's more consistent, and addresses some of my previous objections about how @commandline is used. I no longer see any installed packages listed as being from @@System, and out-of-band installs will indeed now show From repo: @commandline (@@commandline in list context). dnf info on an out-of-band installed package typically shows something like the following:

$ dnf info remi-release
Installed Packages
Name         : remi-release
---✀---
Repository   : @System
From repo    : @commandline

If I do a dnf reinstall remi-release (because the package is in the remi repo), it changes to:

$ dnf info remi-release
Installed Packages
Name         : remi-release
---✀---
Repository   : @System
From repo    : remi

One other thing about source repos: The repos listed in the From repo: field are always repos that exist in the current repo context. In other words, a package's installation source isn't merely a string containing the repo name; installed packages are linked to the identity of the providing repo as it exists (or existed) in the system.

Since most repos are distro-versioned, they get redefined with each new Fedora release. (As e.g. the "fedora" repo becomes the set of packages that make up the new release, a completely different repo from the "fedora" that existed under the previous release.) So, whenever a system-upgrade is done, lots of old repo identities get invalidated.

DNF (or hawkey) used to relegate packages installed from repos that no longer exist to @commandline as their source repo. I say "used to", because that is (thankfully) no longer done. Installed packages that came from a repo that no longer exists will no longer show their source as @@commandline / From repo: @commandline. In fact, dnf info shows that they no longer have any source repo. For example, sitecopy was a Fedora package that's since been retired. I installed it from the fedora or updates repo 7 or 8 releases ago, and still have it installed:

$ dnf info sitecopy
Installed Packages
Name         : sitecopy
Version      : 0.16.6
Release      : 14.fc22
Architecture : x86_64
Size         : 373 k
Source       : sitecopy-0.16.6-14.fc22.src.rpm
Repository   : @System

There is no "From repo:" listed.

This does confusingly mean that dnf list installed will show that package (and others like it) with @System (one @) listed next to it. So in a sense we've just traded one inconsistency for another, as that column is no longer always the source repo with @ prepended. Still, I prefer the current state of affairs.

Footnotes

  1. "...the one that's shown..."
    (Sometimes shown. "Available Packages" won't necessarily show up on every dnf list run: If the installed version of a package is the best available version, it's listed under "Installed Packages" so it would be redundant to also list it under "Available Packages". Using --showduplicates will force an "Available Packages" section which includes all known instances, regardless of version, whether installed or downloadable.)
  • I've updated this answer with some observed changes in F30 compared to F28 (when it was originally written), and also to address the things raised at this duplicate question. – FeRD Jun 29 at 20:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.