Maj vers Debian 11 : paquets obsolètes

Support Debian
#1

Bonjour et bonne année :partying_face:

j’ai mis à niveau un serveur sous Debian 10 vers Debian 11. Tout s’est bien passé.
Le seul truc c’est qu’après la mise à niveau, je me retrouve avec une quinzaine de paquets obsolètes listés par apt list ?obsolete :

gcc-8-base/now 8.3.0-6 amd64  [installé, local]
libapt-inst2.0/now 1.8.2.3 amd64  [installé, local]
libapt-pkg5.0/now 1.8.2.3 amd64  [installé, local]
libdns-export1104/now 1:9.11.5.P4+dfsg-5.1+deb10u8 amd64  [installé, local]
libffi6/now 3.2.1-9 amd64  [installé, local]
libgcc1/now 1:8.3.0-6 amd64  [installé, local]
libhogweed4/now 3.4.1-1+deb10u1 amd64  [installé, local]
libip4tc0/now 1.8.2-4 amd64  [installé, local]
libip6tc0/now 1.8.2-4 amd64  [installé, local]
libisc-export1100/now 1:9.11.5.P4+dfsg-5.1+deb10u8 amd64  [installé, local]
libjson-c3/now 0.12.1+ds-2+deb10u1 amd64  [installé, local]
libnettle6/now 3.4.1-1+deb10u1 amd64  [installé, local]
libprocps7/now 2:3.3.15-2 amd64  [installé, local]
linux-image-4.19.0-23-amd64/now 4.19.269-1 amd64  [installé, local]
perl-modules-5.28/now 5.28.1-6+deb10u1 all  [installé, local]

Selon ce que je sais, les paquets obsolètes sont des paquets qui sont sortis des dépôts Debian et qui donc ne sont plus maintenus. Ça peut du coup entraîner des problèmes de sécurité.
Le soucis, c’est que je ne sais pas si je peux supprimer ces paquets l’esprit tranquille… J’ai vérifié et, à par le paquet libapt-inst2.0, ils ont tous une version plus récentes d’installés.

Ma question est donc, je les supprime et si oui comment ? Un par un ou y a t’il une commande apt ?
Un apt autoremove ne fait rien.
Merci

#2

voir :
https://debian-facile.org/doc:systeme:apt:debianpropre
cela me semble raisonnable

#3 
apt list ?obsolete |awk -F\/ '/\//{print $1}' |xargs sudo apt remove
1 J'aime
#4

Je ferai plutôt un apt purge, mais ça marche aussi.

1 J'aime
#5

Merci pour vos réponses. J’ai supposé qu’elles voulaient dire « vas y supprime ».

Je n’utilise pas aptitude et j’avais lu il y a quelques années que c’était soit apt, soit aptitude mais pas les deux sur un même système.
J’ai voulu utiliser la commande de Verner mais elle se terminait systématiquement par « Annulation » avant que je puisse répondre non ou oui à la question « supprimer ? ».

Du coup, j’ai tout viré avec un apt purge en collant derrière les 15 paquets. Ça a l’air ok, le serveur ronronne tranquillement.

#6

salut
chez moi
apt purge ne résoud pas les paquets obsoletes

Chez Moi :
apt list ?obsolete |wc
37 184 2183
dpkg -l |grep ^rc |wc
56 548 7763

pour enlever les « rc » :
sudo apt-get --purge remove $(dpkg -l |grep ^rc |sed 's#rc *##' |sed 's# .*##'|tr "\n" " ")

#7

Wahou ! Pourquoi faire simple quand on peut faire compliqué -)

Il n’y a pas que sed dans la vie, il y a aussi cut

fp2@debpacha:~$ dpkg-query -l | fgrep linux-image | cut -f 1,3 -d ' '
rc linux-image-4.19.0-17-amd64
rc linux-image-5.10.0-10-amd64
rc linux-image-5.10.0-13-amd64
rc linux-image-5.10.0-14-amd64
rc linux-image-5.10.0-15-amd64
rc linux-image-5.10.0-16-amd64
rc linux-image-5.10.0-17-amd64
ii linux-image-5.10.0-19-amd64
ii linux-image-5.10.0-20-amd64
rc linux-image-5.10.0-9-amd64
ii linux-image-amd64
fp2@debpacha:~$

Les deux espaces qui séparaient ‹ rc › et le nom du paquet se sont transformés en un seul espace. Donc il me semble plus simple d’écrire

dpkg-query -l | grep '^rc' | cut -f 1,3 -d ' ' | cut -d ' ' -f2 | xargs sudo apt -y purge

Je vous conseille d’installer la paquet etckeeper avec git ce qui me permet d’avoir une trace de ce qui a été fait dans la configuration du système. Je me place dans /etc et je lance

fp2@debpacha:/etc$ sudo git log -p --raw

ce qui me permet de retrouver la liste des paquets purgés ainsi que les fichiers de configuration qui ont été supprimés ( l’option -p donne les chemins des fichiers supprimés et leur contenu qui va vers /dev/null ).

Cordialement,
Regards,
Mit freundlichen Grüßen,
مع تحياتي الخالصة

F. Petitjean

« On ne perd pas son temps en aiguisant ses outils. »
Proverbe français

« Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » (R. Devos)

#8

Mouais… du cumul de grep et cut quand tout peut passer dans un simple awk, c’est pas forcément plus simple…
Du coup, en awk, il y a la version fournie par @Verner qui fait intervenir un xarg (plutôt élégant) ou peut-être un peu plus bourrin et compact:

sudo apt purge $(dpkg -l | awk '/^rc / {print $2}')
1 J'aime
#9

Comme la ‹ super mega solution › a consisté à faire ‹ apt purge › sur chaque paquet, je suppose que l’investigation de ta question t’intéressait moyennement, et suppose aussi que tu n’avais pas besoin d’ouvrir un sujet pour te contenter de faire ‹ apt remove ou purge › sur un paquet.

Quelques remarques à toutes fins utiles, ou pas.
1] ‹ purge › n’est rien d’autre que ‹ remove ›, sauf que les fichiers de configuration seront aussi supprimés avec ‹ purge ›.
2] impossible qu’un paquet soit supprimable avec ‹ purge ›, mais pas avec ‹ remove ›;
3] bien que apt list ?obsolete donne un retour, ‹ ?obsolete › n’est pas un argument officiel d’apt, mais d’aptitude.
Le résultat de ‹ ?obsolete › dans mon système est d’ailleurs totalement farfelu, soit pour des paquets installés localement, soit même pour des paquets à jour de la base Debian.
Donc ‹ ?obsolete ›: pas fiable du tout, raison pour laquelle j’ai séquentialisé le listage des paquets, puis xargs en final pour supprimer les paquets.
N’ayant fait qu’une simulation avec ‹ -s ›, je ne vois absolument pas ton problème d’abandon immédiat d’apt, mais sans aucun retour concret de commande, impossible à analyser.
Trop tard, dommage / aurait pu être intéressant à analyser.

Dis donc dindoun, es-tu sûr de ne pas comparer des choux et des carottes ?

• commande 1: nombre de paquets installés, supposés approximativement obsolètes
• commande 2: nombre de paquets non installés/désinstallés, dont les fichiers résiduels de configuration sont présents dans le système.

Ça aurait été un hasard hallucinant d’obtenir le même résultat, d’autant plus que la liste de paquets correspondants aurait été totalement différente entre les deux commandes.

Supprimer des fichiers de configuration de paquets non installés est franchement une opération d’ordre très secondaire (quelques dizaines de Ko), et qui n’a d’ailleurs rien à voir avec la question initiale.

#10

Si tu le dis. M’enfin quand même, respire un coup, tu prends les choses trop à coeur… ;o)

#11

Pour être complet, et que le sujet soit un minimum utile, c’est lorsque tu as voulu supprimer le paquet linux-image-4.19.0-23-amd64 en cours d’utilisation qu’apt a demandé soit d’abandonner (par défaut) ou de poursuivre. C’est le fonctionnement tout à fait nominal d’apt, ce n’est pas un bug.
Que le paramètre ?obsolete trouve qu’un noyau en cours d’utilisation est ‹ obsolète ›, ce n’est qu’une démonstration de plus que la paramètre ?obsolete est à définitivement oublier, encore plus avec apt, puisque non spécifié, non documenté.

#12

Bonjour,

Le noyau courant devrait être un 5.10 si le système a été migré sur Debian11 Bullseye, le noyau 4.19.0-23-amd64 appartient à Debian10 Buster et n’existe pas dans les dépôts de Bullseye ?

A+

#13

Lors d’une mise à jour, le noyau en cours (4.19) n’est pas celui qui vient d’être installé (5.10).
Ce n’est qu’après reboot que le nouveau noyau est utilisé, si tout se passe bien.
Ce dont je suis sûr, c’est que lorsqu’on essaie de désinstaller un noyau en cours d’utilisation, apt ne demande pas juste une confirmation avec oui/non, mais ouvre une fenêtre qu’on ne peut pas rater, en proposant par défaut d’abandonner.

#14

Absolument pas. Mon noyau courant est le 5.10. Si le 4.19 est marqué comme obsolète c’est parce qu’il l’est. Il n’est plus dans les dépôts de debian 11 vers laquelle j’ai migré le serveur (tout comme les autres paquets marqués obsolètes).

Mais vas y, continue à faire tes questions réponses et à prendre les autres pour des imbéciles.

#15

Il l’est évidemment maintenant, mais ne l’était pas 7 jours plus tôt. Tu vois la différence ?
C’est au moment où tu fais un commentaire sur un retour de commande, qu’il faut donner les précisions pour analyser, pour que ta demande ait un minimum d’utilité.
Aucune autre explication possible.

#16

Qu’est ce que tu racontes ? Je le dis noir sur blanc que j’ai migré sous debian 11, donc mon noyau est le 5.10 et le 4.19 est marqué obsolète.
Aller pour ma part, le sujet est clos.
Bye

#17

Personne ne te dit le contraire…
La question n’est pas de connaître l’état de ton système actuel, on s’en moque, mais celui lors de ta demande il y a 7 jours, au moment précis où tu fais une observation sur une commande.
Lorsque tu installes un nouveau noyau, ce n’est pas apt ou dpkg qui t’indiquera le noyau ‹ en cours ›, mais la commande uname -r .
Il y a une sécurité d’apt qui vérifie spécifiquement pour le noyau que la version du noyau en cours ne peut être supprimée qu’après accord explicite de l’utilisateur.
Aucun autre paquet ne provoquera un abandon immédiat d’apt, mais juste des confirmations oui/non, selon le volume de paquets à supprimer.

#18

Tu me prends pour un abruti qui met à niveau un serveur sous debian mais ne le redémarre pas, c’est ça ?
'tain… t’es un champion du monde toi.

#19

Pour moi aussi. Merci de ta coopération, bien qu’un peu tardive.
La prochaine fois, donne les retours de commandes au bon moment, ce sera plus utile et moins confus. La chronologie est importante.
The future proves the past.

#20

Ta commande je l’ai exécutée en étant sous le 5.10 parce que je sais qu’on redémarre après une mise à niveau.

Extrait des logs du serveur :
janv. 14 20:13:32 nuc-debian kernel: Linux version 5.10.0-20-amd64 (debian-kernel@lists.debian.org) (gcc-10 (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 SMP Debian 5.10.158-2 (2022-12-13)
janv. 14 20:13:32 nuc-debian kernel: Command line: BOOT_IMAGE=/boot/vmlinuz-5.10.0-20-amd64 root=UUID=9cf3a5f9-8f7d-4977-b4af-679a73d9b454 ro quiet

Maintenant, tu vas t’excuser ou tu vas continuer à t’enfoncer dans le ridicule ?