Intérêt d'inclure contrib et non-free dans sources.list?

Support Debian
#1

bonjour,

debian 11 / Xfce

pour la future debian 12 je suis en train de reconsidérer l’intérêt de l’introduction des dépôts contrib et non-free dans sources.list . L’expérience m’a montré que non-free m’est indispensable mais uniquement pour certains paquets ( pilotes en particulier ) , quant à contrib , je ne sais pas .

Je n’ai encore jamais essayé de faire le tri dans ces dépôts entre l’utile et l’inutile afin , éventuellement , de n’installer que le minimum . Mais cela en vaut-il la peine ? D’ailleurs est-ce faisable ?

Le site debian-facile semble dire que l’installation de l’ensemble est une bonne chose en utilisant un argument que je ne comprends pas :

Si les paquets issus de ces deux dépôts sont maintenus et distribués en utilisant la même infrastructure que le reste de Debian, ils n’en font officiellement pas partie .Ces paquets étant souvent impossible à inspecter pour des raisons de licence, on doit faire une confiance aveugle aux entreprises fournissant ces logiciels. Mieux vaut-il installer une petite boite noire que de devoir changer des pièces de votre ordinateur ? On va dire que oui et poursuivre !

La boîte noire contenant les dépôts en question , j’ai plus de mal avec la remarque que de devoir changer des pièces de votre ordinateur = changer quoi exactement ? Une carte dont le pilote ne fonctionnerait pas sans non-free par exemple ?

note : en utilisant synaptic je viens de voir que non-free a installé de nombreux paquets alors que contrib n’en a installé que deux :

  • iucode-tool ( pour intel )
  • pepperflashplugin-nonfree ( non-free ET contrib ? ) → que je viens de supprimer car inutile d’après synaptic

Donc là l’installation de ces seuls deux paquets pourrait se justifier , non ? Mais quid de leur mise à jour ?

#2

Salut, les dépots peuvent être présents mais ne pas servir si tu n’installe aucun de leurs contenus :wink: en résumé, activer un dépot n’installe pas du tout la totalité de son contenu (heureusement!)

#3

Les paquets contrib contiennent des trucs libres mais qui dépendent de données non libres, par exemple prboom du temps où Freedoom n’existait pas, ou ezquake aujourd’hui (je ne connais pas de Freequake).

#4

je viens de modifier mon titre qui était mal rédigé .

et donc la liste des paquets non installés qui apparaît dans synaptic n’occupe que très peu d’espace-disque et n’est pas lue systématiquement lors d’une mise à jour par exemple ? Je dis ceci car selon l’extrait ci-dessous wiki il semblerait qu’ignorer ou supprimer des lignes inutiles soit une bonne pratique :

Si vous avez déjà installé la version stable de Debian, pour la mettre à jour vers « testing » :

  1. Modifiez vos sources apt en changeant « stable » (ou bullseye, l’actuel nom de « stable » par « testing » (ou bookworm, le nom actuel de la prochaine version « stable »).
  2. Effacez, désactivez ou commentez vos sources apt de mise à jour de sécurité de la version stable (celles avec security.debian.org dedans).
  3. Effacez, désactivez ou commentez toutes les autres lignes spécifiques telles que *-backports ou *-updates.
#5

Cela me semble pourtant clair, les dépôts Contrib et non-free contient des paquets ou des bouts de codes ayant des licences bloquantes dans la politique habituelle de Debian, mais qui sans eux le PC peux fonctionner moins bien ou pas du tout.

Il me parait plus sage sur ce que l’on appelle un Desktop d’ajouter ces deux dépôts afin de pouvoir bénéficier des microcode lié au processeur et au éléments hardware qui requiert des firmware au code non libre.

Le bluetooth, le wifi, la carte graphique …

Je t’invite à relire le contrat Social de Debian sur leur site pour mieux cerné le pourquoi du comment : Le contrat social de Debian

Si tu commente/supprime les lignes après coup tu ne bénéficiera jamais de mises à jour pour les paquets concernés, pouvant à terme nuire à la sécurité de ton poste voir sait-on jamais bloqués des mises à jour de paquets provenant de la partie principale (voir pas complète, la mise à jour du noyau sans les microcodes/firmwares nécessaires pour des fonctionnalités entraînant la non recréation de l’initramfs).

#6

c’est ce que j’ai vu

je vais donc suivre le conseil de gens d’expérience même si j’aime bien installer le moins de choses possibles sur mon portable : légèreté et agilité vont souvent de pair .

#7

Sur linux c’est toi qui décide ce que tu installes; rien à voir avec les dépots que tu déclares.

#8

Cette page concerne testing, pas les versions stables. Il ne faut pas tout mélanger.

Ça m’étonnerait, un paquet de main ne peut pas dépendre d’un paquet de contrib ou non-free.

#9

idem @Clochette

Si tu commente/supprime les lignes après coup tu ne bénéficiera jamais de mises à jour pour les paquets concernés,

je vois que , comme souvent malheureusement , même si dans mon esprit c’est clair , la traduction écrite de ma pensée laisse à désirer . Et tant pis pour Nicolas Boileau .

Donc , je ne dis pas qu’il faut supprimer des lignes dans sources.list mais que , prenant cette approche de " supprimer ou mieux ne pas inclure " ce qui n’est pas utile je pensais ne pas mettre contrib dans les dépôts car ne me fournissant , d’après synaptic , qu’un seul paquet que je pourrais très bien installer manuellement . Est-ce que ça vaut le coup ? Cela simplifie-t-il et accélère-t-il la lecture des sources ? Cela supprime-t-il une source de bogues potentiels ? Questions peut-être inutiles ou simplistes ou autre qualificatif mieux adapté .

Quoiqu’il en soit je vais suivre le conseil donné par @Clochette qui sait bien mieux que moi ce qu’il convient de faire .

#10

Mauvaise idée car comme on l’a déjà dit tu ne bénéficierais pas des éventuelles mises à jour de sécurité. Si c’est ça qui te chagrine :

La liste des paquets de contrib et non-free est courte, pas de quoi s’embêter avec ça.

#11

ok ; merci pour ces précisions qui donnent une solution définitive à ce mini-problème .

#12

Je suis bien d’accord, mais je n’ai clairement pas assez de recul sur la gestion des firmwares placés dans non libre et contrib qui pourrait-être nécessaire à un moment pour la monté de version d’un paquet utilisant des sources pour recompiler des modules … genre le kernel. (mais comme dit plus haut je ne sais pas).