Re: Site dedie a Debian autre que debian.org ?

[Thierry Laronde <thierry.laronde@polynum.com>]

Le Fri, Jun 11, 1999 at 06:06:35PM +0200, Raphael Hertzog écrivit:
> La solution ? A mon avis, il faut revoir totalement l'arborescence dans
> laquelle les paquets sont installés, il faut permettre une aborescence à
> plus d'un niveau et il faut que la création de nouvelle branches soient
> possibles. Peut-être même faut-il qu'un paquet puisse être présent à
> plusieurs endroits à la fois pour permettre de faire quelques
> regroupements selon des critères différents.
> 
> Exemple de supplément utile aux sections actuelles :
> + science pour stéphane. :-)
> + interpreters/perl
> + interpreters/python
> + net/irc
> + net/ftp
> + net/dialup
> + tasks (pour les paquets virtuels qui permettent juste d'installer
> automatiquement les dépendances avec apt)
> 
> Et ainsi de suite.
> 
> Cela ne veut pas dire qu'il faut supprimer des paquets mais juste les
> réorganiser et permettre à ceux qui le veulent de ne mettre que certaines
> sections sur leurs CDs pour faire des CDs spécialisés.
> 

[ Sur le même sujet, Fabrice Gautier écrivit ]:

  Fabrice> A mon avis ilfaut non seulement reorganiser les sections
  Fabrice> mais revoir aussi la disposition des branches. Je
  Fabrice> m'explique:

  Fabrice> Pour l'instant quand on cherche un paquet pour lire du MP3
  Fabrice> on doit d'abord allez voir dans main puis dans la section
  Fabrice> main/sound (qui est seulement désigné par sound dans
  Fabrice> dselect). Puis on remonte dans l'arbre et va voir dans
  Fabrice> non-free puis dans la section non-free/sound. A mon avis ce
  Fabrice> n'est pas pertinent - du point du vue de l'utilisateur pas
  Fabrice> ce celui des avocats du logiciel libre - car, même si
  Fabrice> l'utilisateur ne veut rester fidèle au "free software" il
  Fabrice> recherche d'abord un logiciel de la section sound. On
  Fabrice> devrait dont d'abord allez voir dans la section sound puis
  Fabrice> si on irait dans sound/free (ou sound/main si vous
  Fabrice> preferez) ou dans sound/non-free. Idem je pense que la
  Fabrice> distinction non-US devrait se faire après les sections. Ce
  Fabrice> qui donnerait au final:

	[...]
[ Auquel Laurent Martelli répondit ]:
> Je pense que l'organisation arborescente est complètement inadaptées,
> à cause des problèmes que tu cites. Il vaudrait mieux je pense
> attribuer des mots clés au paquets afin de pouvoir faire une recherche
> dessus. Toutes tentative de vouloir organiser les paquets dans _une_
> arborescente me paraît effectivement vouée à l'échec. 

Apparemment, pour autant que je le comprenne, nous tournons tous autour des mêmes problèmes, à savoir que dpkg et ses succédanés ont été conçus - à mon humble avis - de manière très saine fondamentalement, mais en partant du principe merleau-pontien que l'utilisateur à la recherche de quelque chose de particulier saurait déjà où le trouver. Or le problème, en tout cas pour moi, c'est que quand je cherche un programme, je sais grosso modo ce que je voudrais qu'il fît, mais que je ne peux pas lancer une recherche générique sur l'*ensemble* des paquetages possibles, en espérant que je vais tomber sur un mot clé me permettant de faire un premier tri.

Alexandre Vitrac ne sera peut-être toujours pas d'accord, mais je persiste à dire que le tri par licence est un a priori idéologique qui ne facilite en rien l'identification des programmes et de leur utilité. Je ne dis pas que la licence n'est pas importante - s'il n'y avait pas eu GNU, il n'y aurait rien eu, en particulier pas Linux - mais, pour l'organisation, il s'agit d'un critère qui doit passer au deuxième plan ( et les exemples de jeux à la con que je donnais dans un précédent message ne sont qu'à peine exagérés puisque j'ai vu passer aujourd'hui un ITP pour un jeu, d'intérêt fort moyen, mais licencié sous GPLv2, ce qui signifie qu'il va se retrouver dans "main", simplement parce qu'un candidat mainteneur voulait avoir quelque chose à mettre en .deb...).

Pour être très général, les programmes sont comme les mots : ils ont un signifiant ( le code, la façon dont ils sont implémentés), et un signifié : ce qu'ils sont supposés faire. A l'heure actuelle, en caricaturant un peu, le code est renseigné - ce sont les dépendances - mais ce que le programme est censé faire se retrouve seulement dans une description dont l'écriture est laissée à la libre appréciation du mainteneur.
Donc, à mon avis, il serait bon de rajouter - comme le propose Laurent Martelli - *au moins* un champ identifiant déjà le groupe générique auquel appartient le programme, histoire déjà de savoir grosso-modo ce que la bête se propose d'accomplir, mais en forçant l'emploi d'un vocabulaire terminal - d'une terminologie- fixe. Et là, on aurait le début de quelque chose, à savoir l'amorce d'un système expert, car rien n'empêcherait d'étoffer le langage progressivement, afin qu'un programme soit identifié par ce qu'il fait, les groupes dont il dépend, toutes informations qui pourront être sondées plus ou moins profondément ( à l'instar des sections de man), du "macro"-niveau de l'utilisateur jusqu'aux appels de bibliothèques.
Par exemple mutt est un *MTA* -ça c'est la section-, mais dont la fonction n'est pas de récupérer à l'extérieur le courrier, ni de le transmettre directement : il nécessite sendmail|smail|exim|postfix, pour la distribution, et fetchmail ou autre pour la récupération - on retrouve donc les dépendances mais au niveau du "signifié", c'est-à-dire de la fonction du programme.

Mais on peut déjà commencer par le plus simple : la section.

Deuxièmement, tous les "en-têtes" devraient être regroupés dans un fichier compressé qui serait l'*image* de la distribution à un moment donné ( ou plusieurs fichiers, mais alors pertinemment construits en fonction de ce à quoi servent les programmes, et non plus en fonction de la licence - libre à celui qui sélectionne de ne garder que du logiciel libre, ou de commencer à programmer s'il n'existe pas).

Troisièmement ( c'est une conséquence de l'organisation) on pourrait songer à une base de données réellement distribuée : dès lors que l'image de la distribution est récupérée par le poste client, que la recherche du programme adéquat est lancée, le poste client ( par dselect, apt ou autre frontal de dpkg) envoie une requête pour traduire l'*identifiant* du paquetage en une URI : les paquetages peuvent être n'importe où sur le net - la sélection entre divers serveurs peut se faire suivant la proximité ou la disponibilité -, de manière opaque pour le client ( je n'aime pas le terme microsoftien de "transparent" puisque justement on cache le travail). On aurait donc un serveur maître qui accueillerait les nouveaux en-têtes et les URI sur lesquels pointer, qui générerait la nouvelle image, que des serveurs secondaires pourraient alors récupérer, tous les serveurs pouvant répondre à n'importe quelle demande, sans pour autant accueillir tous les paquetages ( à la limite, ils peuven!
t n'en accueillir aucun), leur mission principale consistant à *résoudre* en URI les demandes ( des sortes de DNS quoi).

Si alors, le coeur du système est détaché de la gangue des programmes à l'utilité douteuse, il redeviendrait possible de télécharger, même avec un modem, le système, puis de personnaliser en récupérant les sections/les programmes qui nous intéressent.

Encore une fois, il est possible de commencer petit, car une base de données ce n'est rien d'autre qu'un ensemble de données auxquelles on peut d'une manière ou d'une autre accéder individuellement : ça peut se faire dans un fichier texte avec des scripts perl, ou avec awk et sed.

Les commentaires sont bienvenus !

( Alors ce site, on le fait ?:-)

Salutations amicales.
-- 
 /~~~~/-------------------------------------------------
(    (__ Thierry LARONDE
D\_/^ _/ http;//www.polynum.com
Q  \|/   thierry.laronde@polynum.com
M___^___________________________________________________