¿Qué significa '@' delante del nombre del repositorio en `dnf list`?

Cuando quiero enumerar los paquetes instalados, lo hago generalmente de una de dos maneras.

La manera tradicional es usar rpm -qa | grep <whatever I look for>, y eso es todo.

Pero recientemente quería una visualización más completa de mis paquetes y, en adelante, la usé dnf list --installed <whatever I look for>.

Sin embargo, al mirar el resultado hay un par de cosas que no entiendo.

Considere este ejemplo:

# 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

(los espacios en la impresión real son más amplios)

Entonces las entradas resultantes son: «paquete» «versión» «repo».

En mi ejemplo eso es:

• paquete: zsh.x86_64
• versión: 5.2-5.fc24
• repo: @@ línea de comando

Hasta ahora, la tabla resultante es comprensible, pero estoy confundido sobre lo que significan las dos '@@' delante del nombre del repositorio.

Además, "línea de comandos" sugiere que el paquete se instaló desde la línea de comandos (descargando el RPM, y luego haciendo dnf install whatever.rpm en la línea de comando , etc.). Sin embargo, estoy bastante seguro de que he instalado a zshtravés de dnf install zsh.

Pero eso no es todo.

Tengo varios paquetes en mi sistema instalado desde el repositorio @System, @fedora(sin embargo hay también fedorasin el @) y cosas así @@commandline.

Entonces, ¿qué significa eso @o @@exactamente delante del nombre del repositorio?

¿Y por qué tengo tantos paquetes destacados instalados @@commandlineaunque estoy más que seguro de haberlos instalado desde los repositorios?

Déjame tirar un ladrillo para atraer algo de jade aquí.

dnf list all | lessmuestra todos los paquetes (incluidos los paquetes instalados y disponibles). La salida tiene dos secciones: "Paquetes instalados" y "Paquetes disponibles". Todos los "Paquetes instalados" están precedidos por el signo @, mientras que los "Paquetes disponibles" no. Así que creo que las @señales muestran que los paquetes están instalados. Si se instala un paquete pero se eliminó su repositorio original, supongo @@que se da señal.

El código fuente de dnf está alojado en https://github.com/rpm-software-management/dnf . Después de descargar el código src, haga un grep commandline -ri .en el directorio y no devolverá nada. Sin embargo, su página de Github menciona esto,

Realiza la gestión de paquetes utilizando las bibliotecas RPM, libsolv y hawkey.

Así que miro a Hawkey, que está alojado en el mismo proyecto, en https://github.com/rpm-software-management/hawkey . Mirando su código grep -ri commandline ., muestra algunos resultados.

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

Entonces commandlineviene del hawkeypaquete. En cuanto a la pregunta de por qué @comandlinese muestra en el dnf listcomando, mi conjetura es que el dnfcódigo no se usa hawkeycorrectamente.

(Descargo de responsabilidad: no puedo proporcionar fuentes para nada de esto, porque nunca he visto ninguna documentación que realmente discuta estas cosas. La información a seguir es simplemente lo que he podido averiguar a través de la inspección, la experimentación de blackbox, al azar prueba y error, y simples conjeturas antiguas. Además, una advertencia justa, es sobreexpositoria hasta el punto de ser muuuuucho demasiado tiempo).

DNF añade un @ para denotar la cesión temporal de un instalado el paquete se instaló a partir , en el dnf listcontexto. Como notaste:

Tengo varios paquetes en mi sistema instalados desde el repositorio @System, @fedora (sin embargo, también hay fedora sin @) y cosas como @@ línea de comando.

Pero en realidad, nunca verá ningún paquete proveniente de fedorala lista instalada , ya que cada paquete muestra algunos @ -repo como su fuente. (Puede verificarlo ejecutando sudo dnf list installede inspeccionando; no hay repositorios listados sin al menos un signo @). Cuando vea la información de un paquete con dnf info, el From repo:campo " " mostrará ese nombre de repositorio sin el @. (Entonces " From repo: fedora" es absolutamente posible, y equivalente a @fedoraen la lista instalada).

Pero algunos repos se nombran con un @signo en el frente. Como JohnKoch descubrió en las fuentes de Hawkey, "@commandline" se define como el "nombre del repositorio" para "el repositorio de la línea de comandos". Entonces, @@commandlineen el dnf listlistado simplemente indica un paquete instalado From repo: @commandline, un repositorio que confusamente recibió un nombre que comienza con su propio @ -sign.

dnf infoen cualquier paquete instalado se mostrará Repository: @System, que es el @repositorio virtual con otro nombre. Parece que @Systemes el repositorio virtual que contiene el conjunto de paquetes instalados actualmente, y @commandlineel repositorio de origen virtual de donde vino un paquete, cuando no provenía de ningún repositorio.

El significado de @commandliney @System, y su relación entre ellos, parece haber cambiado desde la primera vez que escribí esta respuesta. De alguna manera es más consistente y aborda algunas de mis objeciones anteriores sobre cómo @commandlinese usa. Ya no veo ningún paquete instalado listado como de origen @@System, y las instalaciones fuera de banda ahora se mostrarán From repo: @commandline( @@commandlineen el contexto de la lista). dnf infoen un paquete instalado fuera de banda generalmente muestra algo como lo siguiente:

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

Si hago un dnf reinstall remi-release(porque el paquete está en el remirepositorio), cambia a:

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

Otra cosa sobre los repositorios de origen: los repositorios enumerados en el From repo:campo siempre son repositorios que existen en el contexto de repositorio actual . En otras palabras, la fuente de instalación de un paquete no es simplemente una cadena que contiene el nombre del repositorio; los paquetes instalados están vinculados a la identidad del repositorio proveedor tal como existe (o existió) en el sistema.

Como la mayoría de los repos están versionados en distro, se redefinen con cada nueva versión de Fedora. (Por ejemplo, el " fedora" repositorio se convierte en el conjunto de paquetes que componen la nueva versión, un repositorio completamente diferente del " fedora" que existía en la versión anterior). Entonces, cada vez que se realiza una actualización del sistema, muchas identidades de repositorio antiguas ser invalidado

DNF (o hawkey) utilizado para relegar paquetes instalados desde repos que ya no existen @commandlinecomo repositorio de origen. Digo "solía", porque eso (afortunadamente) ya no se hace. Los paquetes instalados que provienen de un repositorio que ya no existe ya no mostrarán su fuente como @@commandline/ From repo: @commandline. De hecho, dnf infomuestra que ya no tienen ningún repositorio fuente. Por ejemplo, sitecopyfue un paquete de Fedora que desde entonces ha sido retirado. Lo instalé desde las versiones fedorao updatesrepo 7 u 8, y todavía lo tengo instalado:

$ 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

No hay " From repo:" en la lista.

Esto significa de manera confusa que dnf list installedmostrará ese paquete (y otros similares) con @System(uno @) al lado. Entonces, en cierto sentido, solo hemos cambiado una inconsistencia por otra, ya que esa columna ya no es siempre el repositorio de origen con @antepuesto. Aún así, prefiero el estado actual de las cosas.

Notas al pie

1. "... el que se muestra ..."
   (a veces se muestra. "Los paquetes disponibles" no se mostrarán necesariamente en cada dnf listejecución: si la versión instalada de un paquete es la mejor versión disponible, aparece en "Paquetes instalados" sería redundante incluirlo también en "Paquetes disponibles". El uso --showduplicatesforzará una sección de "Paquetes disponibles" que incluye todas las instancias conocidas, independientemente de la versión, ya sea instalada o descargable).