Pourquoi? Parce que c'est un outil trop compliqué pour lui? On ne lui demande pas de s'en servir, ni même de l'installer volontairement, on suggère simplement qu'il soit installé par défaut (ainsi que les includes des librairies les plus courantes) pour simplifier au maximum l'installation de paquets sources. Et, effectivement, c'est peut-être une des meilleures solutions : si on arrive à empaqueter toute la procédure du configure/make/makeinstall dans une seule commande (voire une interface graphique), on offre ainsi la possibilité à tout utilisateur de Linux d'installer du bleeding-edge sans se casser le c*l. Si en prime on ajoute à ça un système efficace de remontée des bugs, c'est la fête du slip.
Si on peut faire cela sans rien changer aux tarballs (il suffit d'avoir un wrapper un peu malin sur la machine qui sache détecter un projet autoconfé et appeller les bonnes commandes au bon moment), ça pourrait valoir le coup de rajouter un petit fichier descriptif, genre LSM, qui indiquerait les différentes options utilisables, l'adresse e-mail pour remonter les bugs, etc.
En fait, tout ça ressemble violemment à un .ebuild (les scripts de compilation de Gentoo), mais l'idée serait de dissocier cela d'un système de port pour l'intégrer dans la tarball. Comme ça, un outil fait pour (et personnalisé pour coller à la distro - qu'elle soit compatible LSB ou pas, c'est son problème) pourra facilement détecter que la tarball est utilisable, proposer éventuellement à l'utilisateur de configurer quelques options (s'il le souhaite, par exemple via un mode "expert") et lancer la compilation et l'installation. Dans l'idée, un tel système pourrait aussi reprendre d'autres idées de Gentoo, comme la sandbox à la compilation, pour éviter qu'une tarball malicieuse ne sème la pagaille.
Pour moi, la principale difficulté (hors le fait de définir ce que l'on veut, mais il est toujours possible de partir d'un .ebuild simple et d'affiner le système avec le temps) vient de la gestion des dépendances. Il faudrait effectivement un moyen pour ce système de savoir ce qui est disponible sur la machine, ce qui peut-être fait via les gestionnaires de paquetages, mais pas de manière portable.
En revanche, ça n'apporte aucune aide aux paquets propriétaires. Mais pour aider à la diffusion de paquets libres, ça pourrait le faire, non?
[^] # Re: Beurk
Posté par Larry Cow . En réponse à la dépêche Amélioration en vue pour l'installation de logiciel sur GNU/Linux.. Évalué à 10.
Si on peut faire cela sans rien changer aux tarballs (il suffit d'avoir un wrapper un peu malin sur la machine qui sache détecter un projet autoconfé et appeller les bonnes commandes au bon moment), ça pourrait valoir le coup de rajouter un petit fichier descriptif, genre LSM, qui indiquerait les différentes options utilisables, l'adresse e-mail pour remonter les bugs, etc.
En fait, tout ça ressemble violemment à un .ebuild (les scripts de compilation de Gentoo), mais l'idée serait de dissocier cela d'un système de port pour l'intégrer dans la tarball. Comme ça, un outil fait pour (et personnalisé pour coller à la distro - qu'elle soit compatible LSB ou pas, c'est son problème) pourra facilement détecter que la tarball est utilisable, proposer éventuellement à l'utilisateur de configurer quelques options (s'il le souhaite, par exemple via un mode "expert") et lancer la compilation et l'installation. Dans l'idée, un tel système pourrait aussi reprendre d'autres idées de Gentoo, comme la sandbox à la compilation, pour éviter qu'une tarball malicieuse ne sème la pagaille.
Pour moi, la principale difficulté (hors le fait de définir ce que l'on veut, mais il est toujours possible de partir d'un .ebuild simple et d'affiner le système avec le temps) vient de la gestion des dépendances. Il faudrait effectivement un moyen pour ce système de savoir ce qui est disponible sur la machine, ce qui peut-être fait via les gestionnaires de paquetages, mais pas de manière portable.
En revanche, ça n'apporte aucune aide aux paquets propriétaires. Mais pour aider à la diffusion de paquets libres, ça pourrait le faire, non?