Comment répliquer la sélection de packages installés d'une instance Fedora à une autre?


16

J'ai un système Fedora (A) où j'ai installé des packages au fil du temps. Maintenant, je veux installer Fedora sur un autre ordinateur (B) et je veux y installer les mêmes packages.

En termes Debian, je veux accomplir quelque chose comme ceci:

$ dpkg --get-selections > pkg_sel_host_a  # on host_a
$ dpkg --set-selections < pkg_sel_host_a  # on host_b

Mais pour être honnête, je veux vraiment une meilleure méthode pour sélectionner les mêmes packages sur le nouveau système Fedora 19 (B): je veux juste installer les packages du système A qui ont été explicitement mentionnés sur une dnf install(ou yum install) ligne de commande - et non ceux qui ont été installés comme dépendances!

Pourquoi? Parce que les dépendances ont peut-être changé - et je ne veux pas installer de dépendances obsolètes sur le nouveau système. De plus, lorsque je supprime des packages, je souhaite également supprimer les dépendances installées automatiquement (éventuellement) inutiles (c'est-à-dire les orphelins).

J'ai trouvé dnf list installed- mais il ne s'affiche pas si un package a été explicitement sélectionné ou simplement installé en raison d'une dépendance.

Comment puis-je obtenir ces informations sur Fedora?

Quelle est la méthode Fedora / dnf pour répliquer les sélections de packages?

Réponses:


12

Depuis Fedora 26, la repoquery sous-commande Dnf prend en charge une nouvelle option pour répertorier tous les packages installés par l'utilisateur:

$ dnf repoquery --qf '%{name}' --userinstalled \
 | grep -v -- '-debuginfo$' \
 | grep -v '^\(kernel-modules\|kernel\|kernel-core\|kernel-devel\)$' > pkgs_a.lst

Contrairement à d'autres méthodes, il répertorie également tous les packages debuginfo. Le grep supplémentaire dans l'exemple ci-dessus les filtre.

Pour installer la liste sur l'hôte B:

$ < pkgs_a.lst xargs dnf -y install

API Dnf

Avec les versions récentes de Dnf (par exemple Fedora> = 23), la base de données de packages peut être interrogée pour les noms de packages installés par l'utilisateur via l'API Dnf Python:

$ python3 -c 'import dnf; b = dnf.Base(); b.fill_sack(); \
  l = sorted(set(x.name for x in b.iter_userinstalled() \
       if not x.name.endswith("-debuginfo") \
          and x.name not in \
             ["kernel-modules", "kernel", "kernel-core", "kernel-devel"] )); \
  print("\n".join(l)) ' > pkgs_a.lst

# dnf install $(cat pkgs_a.lst) # on host_b

Par défaut, dnf installabandonne si un ou plusieurs packages ne sont plus disponibles. Alternativement, dnf peut être forcé d'installer tous les autres:

# dnf install --setopt=strict=0 $(cat pkgs_a.lst) # on host_b

PS: Mettez le code ci-dessus et plus encore user-installed.pyqui prend également en charge d'autres distributions.

historique installé par l'utilisateur

Sur Fedora 23 et versions ultérieures, Dnf fournit le

# dnf history userinstalled

commande qui répertorie tous les packages installés par l'utilisateur. Depuis 2016-11, son utilité est limitée car il n'y a aucun moyen de contrôler sa sortie et il imprime des packages entièrement qualifiés (c'est-à-dire y compris les informations de version).

Limitations installées par l'utilisateur

Notez que le marquage des packages comme installés par l'utilisateur a certaines limitations sur certaines versions de Fedora, pour les systèmes de l'ère Fedora 23 (à partir de 2015-11), les problèmes suivants sont pertinents):

Repoquery

Sur les anciens systèmes Fedora, où Dnf, l'API Dnf et dnf history userinstalledne sont pas disponibles, on peut utiliser le repoquery à la place, par exemple:

$ repoquery --installed \
     --qf '%{n} | %{yumdb_info.reason} | %{yumdb_info.installed_by}' --all \
    | awk -F'|' ' $2 ~ /user/ && ($3 != 4294967295) { print $1 }'  \
    | sort -u > pkgs_a.lst

La deuxième condition awk est utilisée pour exclure les packages qui ont été installés par le programme d'installation. L'ID utilisateur de l'installateur était apparemment stocké sous le numéro 4294967295 - vous pouvez également écrire quelque chose comme ($3 == 0 || $3 == your-user-id).

Notez que cette commande fonctionne sur Fedora jusqu'à la version 21 - mais par exemple pas sur la version 23, car la commande a repoqueryété remplacée par dnf repoquery. Et dnf repoqueryne comprend pas la %{yumdb_info.reason}balise.


Je ne sais pas si cette approche obtiendra tout, je les ai remarqué sur mon système lorsque j'ai exécuté repoquery ...: "Mot de requête yumdb non valide 'raison' pour le paquet installé: HandBrake-cli-0.9.5-1.fc14.x86_64"
slm

@slm, hm, à partir de quel référentiel le frein à main a-t-il été installé? Peut-être que la configuration du référentiel y est pour quelque chose?
maxschlepzig

Je pense que cela aurait pu être un RPM autonome que j'ai installé en utilisant yum localinstall .... J'avais cependant pas mal de colis qui tombaient dans ce camp.
slm

repoquery --installed --qf '%{n} - %{yumdb_info.reason}' --all 2>&1|grep -v "user$"|grep -v "dep$" |wc -lretourné 90 colis.
slm

6

La façon la plus simple et qui a fonctionné pendant longtemps est:

yum-debug-dump => gives file.

yum-debug-restore <file-from-debug-dump>

... qui fonctionne un peu comme la commande get / set selections dpkg, AIUI. Notez également que si vous relisez l'historique, vous pouvez utiliser:

yum history addon-info last saved_tx => gives file
yum load-tx <file-from-addon-info>

... au lieu d'avoir à l'analyser vous-même.


3

Inspiré par slm de réponse , je suis venu avec la suite yum historysolution:

Obtenez tout l'historique détaillé de toutes les transactions d'installation yum (c.-à-d. Aucune mise à niveau), à l'exception de celles exécutées dans le cadre des actions initiales du programme d'installation (transactions 1 et 2 sur mon système, attribuées à l'utilisateur «Système»):

$ yum history list all | awk -F'|' \
                            '$4 ~ /Install/ && $2 !~ /System/ {print $1}' \
    | xargs yum history info > yum_history

Filtrez les packages installés explicitement et coupez les préfixes de version.

$ < yum_history grep '[^-]\<Install\>' | \
  awk '{ print $2 }' \
  | sed 's/\(-[0-9]\+:\|-[0-9]\+\.[0-9]\|-[0-9]\+-\|-[0-9]\+git\).\+\(\.fc1[1-7]\.\|\.noarch\).*$//' \
  | sort > hist_pkg_list

L'expression régulière laide est nécessaire de telle sorte que toutes sortes de suffixes de version correspondent.

Les résultats semblent assez bien sur mon système.

Une comparaison avec le repoquery ansatz (sur mon système):

méthode # packages
―――――――――――――――――――――――――
repoquery 569
repoquery-2nd 216
miam histoire 214

(J'ai canalisé les résultats du repoquery via sort -u)

Pourquoi y a-t-il des différences? Parce que le repoquery inclut tous les packages des transactions 1 et 2, c'est-à-dire tous les packages qui ont été installés par le programme d'installation de Fedora. Cela explique pourquoi le repoquery inclut les packages mentionnés xorg-x11- drv-mga et amis.

La comparaison de repoquery-2nd et yum-history montre que repoquery-2nd est plus précis - il n'inclut pas certains packages déjà supprimés. De plus, il inclut quelques packages (2 sur mon système) à partir des opérations «yum update», semble-t-il.

avertissement

La méthode basée sur l'historique ci-dessus répertorie uniquement tous les packages installés explicitement pendant toute la durée de vie du système. Il n'équilibre pas les packages qui ont été supprimés lors d'une transaction ultérieure. Ainsi, cette méthode nécessite une conservation manuelle des résultats et ne doit être utilisée que sur les systèmes où elle repoqueryn'est pas disponible.


Belle façon de tirer le meilleur parti de nos deux réponses! Je vous donnerais plus d'un +1 si je pouvais pour la solution éventuelle + la belle comparaison des différentes façons de le faire.
slm

2

J'ai une ancienne version de Fedora (14), donc mon yum inclut une version moins riche en fonctionnalités de yum, mais vous voudrez peut-être jeter un œil à la yum historyfonctionnalité. Je crois que vous pouvez obtenir les informations que vous recherchez à partir de cette commande.

liste historique

$ sudo yum history list
Loaded plugins: langpacks, presto, refresh-packagekit
Adding en_US to language list
ID     | Login user             | Date and time    | Action(s)      | Altered
-------------------------------------------------------------------------------
   862 | System <unset>         | 2013-07-12 18:00 | Install        |    1   
   861 | System <unset>         | 2013-07-09 03:11 | Install        |    1   
   860 | System <unset>         | 2013-07-01 13:40 | Install        |    1   
   859 | System <unset>         | 2013-06-29 22:07 | Install        |    1   
   858 | System <unset>         | 2013-06-25 22:33 | Install        |    1 P<
   857 | System <unset>         | 2013-06-23 22:28 | Update         |    1 >E
   856 | System <unset>         | 2013-06-23 21:33 | Install        |    1   
   ...

Vous pouvez revenir à la toute première transaction en passant une liste de numéros à yum history list:

$ sudo yum history list `seq 1 10`
Loaded plugins: langpacks, presto, refresh-packagekit
Adding en_US to language list
ID     | Login user             | Date and time    | Action(s)      | Altered
-------------------------------------------------------------------------------
    10 | Sam M. (local) <saml>  | 2010-12-18 23:23 | Install        |    2   
     9 | Sam M. (local) <saml>  | 2010-12-18 23:15 | Install        |   38   
     8 | Sam M. (local) <saml>  | 2010-12-18 23:12 | Install        |    1   
     7 | Sam M. (local) <saml>  | 2010-12-18 23:09 | Install        |    1  <
     6 | Sam M. (local) <saml>  | 2010-12-18 22:37 | Install        |    1 > 
     5 | Sam M. (local) <saml>  | 2010-12-18 21:57 | Install        |    1   
     4 | System <unset>         | 2010-12-18 21:21 | Install        |    5   
     3 | System <unset>         | 2010-12-18 21:18 | Install        |    4   
     2 | System <unset>         | 2010-12-18 21:10 | Install        |    3   
     1 | System <unset>         | 2010-12-18 19:14 | Install        | 1189

info historique

Ce qui suit vous montrera ce qui a été installé dans le cadre de la première transaction yum:

$ sudo yum history info 1 | less
Loaded plugins: langpacks, presto, refresh-packagekit
Adding en_US to language list
Transaction ID : 1
Begin time     : Sat Dec 18 19:14:05 2010
Begin rpmdb    : 0:da39a3ee5e6b4b0d3255bfef95601890afd80709
End time       :            19:42:43 2010 (1718 seconds)
End rpmdb      : 1189:8c21e9e377c3ebdee936916208f74232d5d6235f
User           : System <unset>
Return-Code    : Success
Transaction performed with:
Packages Altered:
    Dep-Install ConsoleKit-0.4.2-3.fc14.x86_64
    Dep-Install ConsoleKit-libs-0.4.2-3.fc14.x86_64
    Dep-Install ConsoleKit-x11-0.4.2-3.fc14.x86_64
    Dep-Install GConf2-2.31.91-1.fc14.x86_64
    Dep-Install GConf2-gtk-2.31.91-1.fc14.x86_64
    Dep-Install ModemManager-0.4-4.git20100720.fc14.x86_64
    Install     NetworkManager-1:0.8.1-10.git20100831.fc14.x86_64
    Dep-Install NetworkManager-glib-1:0.8.1-10.git20100831.fc14.x86_64
    Install     NetworkManager-gnome-1:0.8.1-10.git20100831.fc14.x86_64
    Install     NetworkManager-openconnect-0.8.1-1.fc14.x86_64

Remarquez comment yum indique si un package a été explicitement installé ou installé car il était nécessaire à une dépendance. Vous pouvez analyser ces informations et obtenir votre liste de packages qui ont été explicitement installés.


J'ai ajouté une réponse basée sur votre yum historyidée, elle compare également les résultats avec la repoqueryméthode basée. Comme effet secondaire, j'ai étendu ma réponse au repoquery.
maxschlepzig

1
dnf repoquery --qf "%{name}" --userinstalled > userinstalled.txt

1
En examinant les 5 autres réponses ici, que remarquez-vous qui est différent dans votre réponse? Il n'y a absolument aucune explication de pourquoi ou comment votre réponse est meilleure ou différente. Ce serait bien si vous pouviez fournir une description de votre réponse qui couvre ces choses.
Stephen Rauch

@StephenRauch, cette commande n'est pas incluse dans les autres réponses, car il s'agit d'un ajout dnf récent. Le --userinstalledcommutateur vient d'être ajouté à dnf en mai . Je l'ai testé et il donne des résultats précis. Modulez les paquets kernel / kernel-core / kernel-modules qui ne sont pas vraiment installés par l'utilisateur. Il contient également tous les *-debuginfopackages, mais ils peuvent être facilement filtrés si nécessaire.
maxschlepzig

@maxschlepzig, merci pour les commentaires, mais c'était en fait un peu une question rhétorique, essayant d'éduquer / inciter le répondeur à expliquer cela dans la réponse.
Stephen Rauch

@StephenRauch, honnêtement, une modification serait certainement appropriée et me permettrait de la marquer comme réponse acceptée.
maxschlepzig

0

Pour lister les packages que vous avez installés, essayez ce one-liner :

alias yum-userinstall="yumdb search command_line install* | grep command_line\ = | sort | uniq | sed -r -e 's/command_line = (.*)/yum \1/g'"

Résultat:

# yum-userinstall
     yum install bind-utils
     yum install http://rpms.remirepo.net/enterprise/remi-release-7.rpm
     yum install https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm
     yum install lsof
     yum install nano
     yum install nfs-utils libnfsidmap
     yum install nmap-ncat
     yum install openscap-scanner
     yum install open-vm-tools

PS1: il ne montre pas de dépendances

PS2: il est trié par ordre alphabétique

PS3: il ne s'affiche pas si vous avez supprimé le package plus tard


-1

Ce que j'ai fait (j'ai oublié les détails, et je suis un clochard paresseux, alors ...

Obtenez tous les packages installés: rpm -qa > file

Utilisez sed(1)pour vous débarrasser des numéros de version et autres (conservez l'architecture, si nécessaire). Cela a nécessité quelques itérations pour bien faire les choses, vous voulez remplacer le dernier tronçon de -[0-9.]-[0-9].fc23ou similaire par rien, mais il y a aussi des "numéros" drôles de version.

Après l'installation comme d'habitude, faites un yum -y install $(< file)(ou dnf, si nécessaire).

Vous obtiendrez des retombées de packages qui n'existent plus, ou changé de nom, ou ont été remplacés par d'autres.


D'accord, mais cela marquera tous les packages précédemment installés comme installés par l'utilisateur sur l'hôte de destination. Même s'ils n'étaient à l'origine installés qu'en tant que dépendances.
maxschlepzig
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.