Fatigué de contrib.

diff --git a/Debian/debiâneries/contrib.mdwn b/Debian/debiâneries/contrib.mdwn
new file mode 100644 (file)
index 0000000..045a2dc
--- /dev/null
+++ b/Debian/debiâneries/contrib.mdwn
@@ -0,0 +1,33 @@
+[[!meta date="Sun, 07 Oct 2012 22:08:31 +0900"]]
+[[!meta updated="Sun, 07 Oct 2012 22:08:31 +0900"]]
+[[!tag Debian]]
+
+[[!meta title="A-t-on vraiment besoin de « contrib » ?"]]
+
+Le projet Debian distribue des paquets de logiciels via son archive, propagée à
+travers un réseau de miroirs.  Cette archive est organisée en trois zones,
+_main_, qui contient le système Debian, et _contrib_ et _non-free_ qui
+contiennent des paquets accessoires qui ne sont pas libres.  Les paquets dans
+_non-free_ contiennent des fichiers dont la license est privatrice.  Les
+paquets source dans _contrib_ ne contiennent que des fichiers libres, mais les
+paquets binaires produits sont soit inutilisables sans service extérieur, soit
+contiennent des fichiers non libres ou demandent l'installation de paquets non
+libres.
+
+La zone _contrib_ est l'objet de sempiternelles questions car il n'est pas
+toujours facile de tracer une ligne entre utilisable et inutilisable.  Je me
+demande s'il ne vaudrait pas mieux remplacer la zone _contrib_ par une nouvelle
+priorité « remote » dans la zone _main_, plus basse qu'_extra_.  Les paquets
+entièrement libres (source et binaire) et ne causant pas l'installation de
+logiciels privateurs y auraient leur place.  Pour les paquets qui ne peuvent pas
+fonctionner sans code privateur, étant donné que l'effort sera le même pour les
+libérer que ce code privateur soit inclut dans le même paquet source (cas de
+_non-free) ou non (cas de _contrib_), je pense qu'on devrait les placer dans
+_non-free_ dans tous les cas : ils ne sont pas libres en pratique.
+
+Cela permettrait de trancher avec un critère simple : la sélection d'un paquet
+binaire entraînera-t-elle l'installation de fichiers non libres ?  Si oui, le
+paquet et sa source appartiennent à _non-free_.  Si non, ils appartiennent à
+_main_.  Ensuite, s'ils demandent l'accès à un service extérieur impossible à
+mettre en place sur un réseau où seule Debian serait disponible pour
+fonctionner comme documenté dans leur description, leur priorité sera _remote_.