Ce n’est pas un jugement de valeur. j’aurais pu en faire un mais ce n’a pas été le cas je me suis retenu.
En tout cas, faire de ta debian une Frankendebian n’est pas une solution technique.
et oui parfois nos choix peuvent etre de mauvais choix, ca arrive à tout le monde.
Comme je l’ai dis plus haut c’est un choix que j’assume et qui ne regarde que moi. Bonne journée.
Pour les applis, utilises les tarball et compile à la main. Cela t’évite la Frankendebian tout en ayant la dernière version de ton application.
ou utilises directement la SID.
As-tu par hasard voulu faire un peu de tuning sur dpkg ?
Techniquement le pinning n’empêche pas de maintenir à jour les paquets installé hors des branches ayant habituellement priorité.
Lorsque APT fais son taff il check les numéros de versions des paquets installés et ceux du référentiel, si ceux du référentiel sont plus à jour il les installera après validation de ta part dans lors d’un UPDATE.
pour exemple peux-tu nous fournir le retour d’un apt policy de paquets n’étant pas à jour ?
Grosso modo le fichier préférences est là pour trier surtout lors de l’installation et la mise à jour pour prioriser des versions par rapport à d’autres c’est tout.
Idem libre à toi d’utiliser les termes stables etc … personnellement je recommande systématiquement d’utiliser les noms de versions pour éviter les bascule non voulu lors d’un upgrade après période de release (c’est même fortement recommandée par Debian eux même).
Idem pour tous ce qui touche à la libc6 :
libc6
Si vous êtes sous stable et que vous voulez installer un paquet de la branche testing, ou même unstable, qui impliquerait des mises à jour aussi importantes que libc6 , alors abandonnez, le pinning ne sera pas une solution pour vous, puisqu’il romprait la stabilité du système et effectuerait une mise à jour partielle vers testing, ce qui est la pire des situations possibles.
Et peux m’importe ce qu’en pense les gens n’appréciant pas les snaps, cela reste une solution simple pour avoir un soft à jour et maintenu, l’espace disque n’est plus la même galère sur nos postes de travail qu’auparavant, on va pas pleurer pour quelques centaines de mega ou un 1 Giga …
En revanche, l’utilisation des snaps n’implique-t-elle pas de charger potentiellement plusieurs versions d’une même bibliothèque en mémoire (je connais pas bien) ? Personnellement je préfère éviter, mais ça reste en effet une solution assez pratique dans le cas d’incompatibilités avec les dépendances utilisées sur le système.
Bonjour,
Non pourquoi ?
En effet mais cela place Stable comme étant prioritaire sur bullseye-security, d’où mon problème…
En effet…
En version Stable 11.5 il doit y avoir environ une cinquantaine de paquets concernés dont Chromium (stable v 104.x vs security v 106.x). Leur liste complète doit être dispo quelque part sur le net. Comme j’ai activé Proposed-Update pour éviter les trou de sécurité, je peux difficilement t’en faire la liste. Surtout et avant tout je ne désir pas devoir gérer ces paquets un à un à la main…
Oui et si il reconnaissait l’expression ci-dessous, j’en serai bien aise, mais malheureusement ce n’est pas le cas ;-(
Package: *
Pin: release a=bullseye-security
Pin-Priority: 999
En effet !!
J’adore bidouiller mon système comme j’en ai l’envie. Et Debian qui est très souple d’utilisation s’y prête très bien ce qui fait mon bonheur 
Par contre, je fais partie de ceux qui n’apprécient pas Snap ce pour des raisons techniques. Mais j’utilise de temps en temps Flatpak qui est sympa et qui peut en effet dépanner de temps en temps, mais malheureusement cette solution n’est pas adaptée à mon problème actuel…
Pour information, les dépendances nécessaires au fonctionnement des paquets Flatpak et / ou Snap sont fournies avec ces paquets Flatpak et / ou Snap, exclusivement pour ces paquets là, et non pas par le système… Il n’y a donc pas de problèmes de conflits de versions.
Oui justement, ça fait potentiellement deux fois (ou plus) la même bibliothèque chargée. Le « problème » n’est pas le conflit de versions, mais une sur-utilisation de ressources. Et autant pour l’espace disque c’est pas du tout problématique, autant pour la RAM, selon les configs et les utilisations, ça peut être dommage.
Les dépendances des paquets Flatpak et Snap se chargent en RAM en parallèle de ces paquets et se referment avec eux aussi, elles ne fonctionnent qu’avec ces paquets là. Les paquets .deb ont eux aussi leurs dépendances bien à eux. Il n’y a donc aucune interférences, mais il est sûr qu’en matière d’utilisation de d’espace disque et de la RAM ça alourdi quelque peu les systèmes…
Ce que personnellement je reprocherai aux paquets Snap est leur lenteur d’exécution (jusqu’à 4-5 secondes pour lancer une application la première fois après un reboot) ainsi que le fait que ces paquets Snap intègrent leurs dépendances dans le même paquet de l’application Snap concernée. Moralité si une dépendance devient obsolète, c’est tout le paquet Snap qui doit être reconstruit. Un paquet Snap peut donc devenir vulnérable en raison d’une seule et unique dépendance, ce doit être un véritable casse tête à gérer au niveau sécurité…
Montre nous le retour de apt policy sur ta machine .
Tu verra que tu peux fixer les security ainsi que les noms de version.
pour fixer un nom plutôt que stable utilise n=stretch … appui toi si tu aime bricoler sur le retour de apt policy pour fixer ce qui doit l’être.
Donc on remplace le a= par un n= ^^ AptConfiguration - Debian Wiki ^^
stable et bullseye-security doivent avoir un poids égales, encore une fois ton fichier préférences en entier sur ce forum et le retour de apt policy pour y voir clair 
Oui, après la plus part du temps c’est pas une trentaine d’appli que l’on charge ainsi donc ça limite tout de même la surcharge, même si j’avoue que passer à 32Go sur le portable devrait me laisser bien plus de marge pour ma part (bveaucoup de docker et compagnie simultané sur mon poste).
Au bûcher … Manjaro et Archlinux c’est une plaie à maintenir sur un poste alors un parc complet …
à la limite Gentoo a de gros avantages idem c’est une plai à maintenir.
Une Debian en rolling release ? Ce n’est techniquement pas possible, on ne peut pas avoir un système aussi fiable et stable que Debian avec des paquets qui changent tout le temps de version.
Et puis, les paquets de Debian stable ne sont pas si obsolètes que ça. Pour ce qui est du matériel, la version du dépôt rétroporté du noyau est quand même assez récente.
1 J'aime
Il faudrait que je refasse une install propre pour ça…
Il va juste me désigner la version installée et m’indiquer que je peux réaliser une mise à jour manuellement issue d’une répertoire autre, je me trompe ? Moralité ça ne va pas m’avancer beaucoup, je ne peux pas faire ça avec tous les paquets concernés, ni vérifier chaque jours qu’ils n’a en a pas de nouveaux à gérer eux aussi…
Donc selon toi je peux ajouter :
Package: *
Pin: release n=bullseye-security
Pin-Priority: 999
à
Package: *
Pin: release a=stable
Pin-Priority: 900
Et ça devrait aller me chercher les mises à jour de sécurité quand elles sont dispo à la place des versions stables ?
Je ne peux pas te faire de retour de apt policy, il faudrait que je refasse une install « propre » pour ça en raison des mises à jour de Proposed-Update qui se sont installés sur ma machine…
Manjaro ça me semble trop facile à installer et à maintenir, à l’image d’une Ubuntu. A ce que j’a compris ils intègrent leurs propres noyaux et ils laissent passer un délai de 2-3 semaines avant d’intégrer les mises-à-jour en provenance de Arch histoire d’être sûr que tout se passera bien.
Arch en tant que distribution mère m’intéresse beaucoup plus, elle est beaucoup plus technique à installer et à maintenir, ce qui n’est pas fait pour me déplaire, mais c’est parfois un peu rude je dois l’admettre. Depuis 2-3 mois que j’ai une installé de Arch de test en dur sur un ssd externe qui tourne plutôt bien, mais ce n’est pas sans soucis… J’aimerai bien pouvoir bénéficier du meilleur de ces deux mondes, c’est à dire pouvoir profiter de la modularité de Debian sur fond de logiciels tous frais à la Arch
Il faudrait une Debian en Rolling Release qui remplace la branche Unstable actuelle avec des paquets mis à jour plus souvent qu’actuellement et une Debian Stable pour ceux qui veulent du stable. Ca serait vraiment génial et loin d’être impossible.
En l’état il est sûr Debian est très cool, j’aime beaucoup. Mais pouvoir utiliser les tout derniers noyaux, ça offre beaucoup de confort d’utilisation avec du matos récent et puis ça apporte de nouvelles fonctionnalités et des corrections de bugs…
Nope, ça ajoute du travail, concernant les bogues de sécurité ils sont traités rapidement chez Debian quelque soit la branches lorsque cela touche le noyau.
Aucun intérêt, les mises à jour arrivent dedans quand elles sont assez mature, la rolling release ce n’est pas juste les paquets c’est tout le système et justement comme dit chez Debian c’est costaud, chez Arch les pieds d’argiles sont fragile.
Manjaro idem ils ont déjà eu nombre de critiques à ce propos.
C’est pas pour rien que la plus part des clients tournant sur CentOS vont soit faire marcher la planche à billet pour passer chez Redhat soit tourner les talons vers Debian , ils veulent pas que ça bouge ils veulent de l’uptime 
Toi tu veux bricoler sur du matos récent …
1 J'aime
On n’est pas du même avis voilà tout, perso je préfère les Rolling Release, chacun son truc, il parait qu’il faut de tout pour faire un monde Je reste très intéressé par Arch voir Manjaro dont je vais suivre l’évolution de prêt !!!
Après je suis un privé je ne roule que pour moi-même et je n’ai que deux machines physiques à administrer Mes sensibilités seraient certainement différentes si j’avais tout un parc de machine à gérer.
Oui, j’ai vu qu’ils avaient changé la politique de support pour CentOS, ça doit faire grincer des dents !! Remarque ils peuvent toujours adopter Fedora. Redhat je ne suis franchement pas fan (ni de system.d d’ailleurs) bien que ce soit la première distrib Linux que j’aie testée il y a un paquet d’années.
Il y a une troisième option qu’a d’ailleurs choisit un de mes clients (qui est une entreprise d’intérêt stratégique dont la sécurité est prise en compte autant pas le ministère de l’intérieur que celui de la défense) qui est Rocky Linux qui va remplacer CentOS.
je n’en connais cependant pas trop les modalités et les différences avec CentOs qui sont au niveau des releases plus que du packaging.
RedHat a été souvent la première distribution utilisée au début parce que c’était la seule facilement accessible pour des débutants; la slackware étant difficile d’accès à cette époque, et Suse pas encore mature.
Bonsoir Clochette,
Il faut que je te remercie pour notre discussion et pour le liens fourni qui m’a permis de revoir ma politique de gestion des Pin-Priority.
C’était la valeur ci-dessous qui posait le problème au niveau des mises à jour de sécurité car elle mettait leur priorité à -10 :
Package: *
Pin: release o=Debian
Pin-Priority: -10
J’ai pu aussi supprimer d’autres entrées inutiles… Je te dois un verre si on se croise un jour
Tout de bon à toi et bonne continuation.
1 J'aime
Ravi que tu es y soit arrivé, bonne continuation.
1 J'aime
J’ai une approche légèrement différente pour avoir Debian (stable ou testing) + quelques paquets d’unstable :
$ cat /etc/apt/apt.conf.d/00default
APT::Default-Release "bookworm";
(Car là sur mon laptop j’ai une bookworm, à adapter à vos envies bien sûr.)
Je sais que tout le monde le fait avec preferences.d et je ne me souviens plus de pourquoi je fais comme ça 
Je vous répond avec un peu de retard…
Dans preferences.d j’ai un fichier que j’ai appelé backport qui contient :
Package: *
Pin: release a=bullseye-backports
Pin-Priority: -99
j’ai également un autre fichier que j’ai appelé stable-prioritaire qui contient :
Package: *
Pin: release a=testing
Pin-Priority: -99
Package: *
Pin: release a=unstable
Pin-Priority: -99
Ainsi tout fonctionne au poil pour moi.
Vous pouvez encore rajouter comme dans l’exemple ci-dessous une fonction pour mettre à jour automatiquement des paquets de type backport ou autre (à placer dans le fichier backport dans ce cas là) :
Package: linux-image-amd64
Pin: release a=bullseye-backports
Pin-Priority: 990
Package: linux-headers-amd64
Pin: release a=bullseye-backports
Pin-Priority: 990
Package: firmware-linux
Pin: release a=bullseye-backports
Pin-Priority: 990
Dans cet exemple on mettra automatiquement à jour les paquets liés au kernel quand de nouvelles versions seront disponibles dans backport.
Bien à vous.
PS Dans mon cas j’ai suivi un tuto erroné sur Debian Facile qui m’a mis dans cette facheuse situation…
1 J'aime