Debian stable plus répertoire Unstable

J’ai une machine avec une install de Debian 11 Stable + le dépôt Unstable notamment pour bénéficier du dernier kernel dispo.

Dans /etc/apt/preferences.d je dois créer un fichier gérant les priorités de ces 2 dépôts qui désigne Stable comme étant prioritaire de sorte à ce que mon système ne migre pas totalement vers Unstable suite à une mise à jour du système dans le genre de apt dist-upgrade

Mon problème c’est que du coup en fixant la priorité sur Stable, je perd les mises à jour de sécurité et je n’ai plus que des versions de softs stables non patchées à ma disposition. La meilleure alternative que j’aie trouvé est d’activer le répertoire Proposed-updates en plus des 2 autres pour compenser.

Y aurait-il une autre alternative à cela ?

J’ai mis ton sujet dans #support, pour que les gens le voient.

Je n’ai pas tout compris, mais il me semble qu’il te prends la version issue de Debian 11 automatiquement, si tu veux une version moins prioritaire et issue d’un autre dépôt, il faut que tu le précises.

apt install -t unstable linux-image-arm64

ou

apt install linux-image-arm64/unstable

Concernant le paquet, je ne sais pas si tu vas avoir besoin de celui-ci, c’est pour l’exemple.
Concernant le nom unstable, il me semble que c’est ça, je ne pratique pas cette version de Debian.

D’autre part, je te rappelle l’existence des dépôts rétroportés, qui peut être une solution te permettant d’éviter de fabriquer un Frankendebian.

Bonjour Almtesh et merci pour ton message.

Comme je l’ai écrit j’utilise une Debian 11 Stable. Le problème est que des fois un soft est buggé et on peut avoir besoin d’une version plus récente pour palier à ce bug, ou on peut avoir besoin par exemple d’un kernel plus avancé pour du matos très récent.

Alors oui il y a le répertoire Backports ou l’on peut trouver quelques softs plus récents et on peut demander aux gentils développeurs / mainteneurs qui en ont le temps de nous y fournir des versions plus récentes. Le problème est que cela prend du temps de les contacter et qu’eux même n’ont pas forcément toujours le temps de s’en occuper… Donc on est +/- forcé à un moment donné de faire des choix, soit on se sert dans d’autres dépôts, soit on change d’OS…

J’adore Debian et j’aimerai continuer à l’utiliser donc je fais avec… De toi à moi, si il y avait une version dispo de Debian sous la forme d’une Rolling Release tel que le propose Arch Linux, je la choisirai très certainement comme distribution principale.

Donc oui je créé une sorte de FrankenDebian, ce que j’assume pleinement.

Si le répertoire Backports une fois activé ne force pas la mise à jour de l’ensemble du système mais nous permet d’installer des paquets individuels choisi manuellement, ce n’est malheureusement pas le cas de Testing ou Unstable qui une fois activé peuvent mener à une mise à jour complète du système.

Pour éviter cela on est obligé de créer des fichiers dans /etc/apt/preferences.d permettant de gérer les priorités et de mettre Stable en avant dont le contenu ressemble à ça :

Package: *
Pin: release a=stable
Pin-Priority: 900

Package: *
Pin: release a=stable-updates
Pin-Priority: 900

Package: *
Pin: release a=proposed-updates
Pin-Priority: 900

Package: *
Pin: release o=Debian
Pin-Priority: -10

Package: *
Pin: release n=testing
Pin-Priority: -99

Package: *
Pin: release n=unstable
Pin-Priority: -99

Le problème est que du coup on pert les mises à jour de sécurité fournies par bullseye-security et si on installe par exemple Chromium on se retrouvera avec une version 104.x au lieu d’une version 106.x ce qui n’est pas top de nos jours niveau sécurité…

La seule alternative que j’aie trouvée est d’activer le répertoire Proposed-updates, ce qui permet malgré tout d’avoir des softs patchés au niveau sécurité entre 2 versions mineures (11.5 à 11.6 par exemple), ce qui est indispensable de nos jours.

Je suis donc à la recherche d’une solution potentiellement plus fonctionnelle élégante pour que le répertoire bullseye-security fonctionne nativement dans mon cas.

Si Debian s’inspirait de Arch voir de Manjaro pour lancer une Rolling Release qui fonctionne aux petits oignons, j’en serai vraiment trop content. Je pense que ce type de distributions sont l’avenir de Linux au niveau sécurité et disponibilité de fonctionnalités avancées. Y a pas mieux pour avoir un système bien sécurisé et des softs récents qui font ce que l’on attend d’eux. La version de Debian Stable est excellente mais elle n’est pas assez mise à jour / maintenue de mon point de vue et on ne peut pas, dans bien des cas, attendre 2 ans pour que la prochaine évolution majeure de notre OS préféré corrige enfin des bugs qui nous handicapent…

Bonjour,

le plus souvent le repo backports suffit et évite les instabilité sur ta « stable »

Non pas vraiment. du moins pas en ce qui concerne des installations de production, bien au contraire.
car introduire de l’instable c’est mettre le serveur et l’infrastructure dont il dépend en insécurité. Et au regard des nombreuses attaques récente par ransomware, je pense qu’il vaut mieux avoir un système comme debian, ou red-Hat ou Ubuntu ou il y a un véritable cloisonnement organisationnel (a defaut qu’il soit technique).

Aucune infra de production n’utilise de la SID (sauf pour le Ev éventuellement, mais ce n’est pas de la production).

Quelles applications, cite des exemple, sinon, désolé de le dire comme ça, c’est du vent, du « on-dit » et rien d’autre.
A ma connaissance actuellement, il n’y a pas de matériel qui ne puisse être supporté par debian 11 Bullseye, aux firmware près. les noyaux tournent.
Donc sur les cas liés au firmware, il faut gérer au cas par cas. la méthode est cependant souvent la même.

Pour ce qui est des applications buggué et d’avoir la dernière version, forcement instable car non testée, il y a Windows, c’est comme ça que ce système fonctionne, au détriment des utilisateurs bien sur, et pas au même prix (meme si free speech and not free beer).

mais tu ne peux pas demander de faire un système Debian comme une archi Arch ou Manjaroo avec une architecture qui n’est pas la même, ni un objectif qui n’est pas le même.

Bonjour,

Il suffit quelques fois, mais pas à chaque fois… sans quoi je ne serai pas là à en parler. Je ne suis pas intéressé par un débat à ce sujet mais par une l’obtention d’une solution allant dans le sens de la politique de mises-à-jour que j’ai mis en place.

Si j’avais un serveur sous Debian Stable, je n’installerai que le minimum de softs met je le laisserai en l’état. Là je suis sur une station de travail et j’ai besoin de plus que ce m’apporte de base Debian Stable.

Je ne vois pas l’intérêt de lister les softs qui m’ont posés problèmes mais si tu en veux 2-3 il y a eu GDebi, Soundconverter, j’ai aussi dû bidouiller le gestionnaire audio à l’époque pour le rendre compatible avec un casque Bluetooth, etc…

Arch à des qualités indéniables que Debian devrait intégrer. En plus de Debian Stable je serai ravis qu’une vraie Rolling Release de Debian soit disponible à la place de la branche Unstable… Après si ce n’est pas ton truc, je respecte bien que cela ne m’avance à rien, mais saches que me concernant c’est le miens de truc…

Enfin bon merci de ne pas commenter mes choix ce qui est inutile et non constructif, je recherche juste une solution au problème que j’ai soulevé…

Alors tu n’as pas choisi la bonne distribution. Et ta problématique est directement issue de tes choix. Encore un probleme XY en fait.

STP évite ce type de jugement de valeurs qui ne mène à rien, tu as ta vie et tu fais tes choix, laisse les autres en faire de même sans leur imposer ton point de vue. Bonne journée à toi.

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 :slight_smile: 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 :wink:

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 :slight_smile:

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…