Journal : Distributions Linux, vers un éclatement des formats de paquetages ?
Posté par Farvardin (page perso, ) le 27 octobre 2006
Cher Journal,
aujourd'hui vendredi, jour propice à la discussion, quelques idées et frustrations me trottaient dans la tête.
Jusqu'à présent j'étais plutôt habitué à l'utilisation de Debian, et sans remettre en cause ceci j'ai commencé à tester d'autres distributions. C'est alors que j'ai remarqué que ce qui me semblait normal sous Debian ne l'était pas forcément ailleurs, par exemple certains programmes se retrouvent dans /usr/bin sous debian, alors qu'ailleurs ils sont installés par défaut dans /usr/local/bin, de même on peut avoir des applications graphiques dans /usr/bin, et ailleurs on les retrouve dans /usr/X11R6/bin, voire dans /opt etc. Sans vouloir défendre plus un point de vue qu'un autre, pour parler franchement est-ce qu'il n'est pas débile de faire un format de paquet par distribution, les paquets d'une distribution à l'autre ne s'échangeant pas forcément très bien ? (dépendances etc.)
Si j'ai bien compris le format .deb est arrivé le premier (cf. wikipedia à propos du Linux Standard Base), puis .rpm, mais d'une distribution à l'autre, les rpm ne sont pas forcément compatibles. Donc on a des rpm spécifiques à red had, fedora, d'autres à mandriva, opensuse, des deb spécifiques à debian, d'autres à ubuntu (pourquoi n'ont-ils pas sorti des .ubu à la place ?), et puis des tgz pour slackware, et si on peut convertir de l'un à l'autre avec la commande alien (de deb à rpm et vice versa), d'une distribution rpm à l'autre c'est plutôt hasardeux, pour ce que j'ai vu (et idem de debian à ubuntu)
J'ai trouvé aussi qu'il existait un genre de consortium Filesystem Hierarchy Standard, mais que cela n'avait pas été respecté non plus.
Il en va de même pour les fichiers de configuration, et tout cela contribue à faire un joyeu bordel pour qui veut s'y retrouver un peu. Alors on va dire que c'est la diversité qui fait la force du libre, mais je trouve dommage (j'ai écrit "débile" plus haut) que les efforts des empaqueteurs soient dispersé à cause de cela. Si quelqu'un passe (qui a dit perd ?) du temps à empaqueter pour Debian, son travail ne sera pas utile pour ceux qui utilisent opensuse ou fedora, etc. Même s'il existe des outils comme smart install, ce n'est pas la panacée non plus, et le système linux me semble un peu affaibli par cet éclatement.
Alors parfois les acteurs des solutions Unix arrivent à s'entendre pour avancer (comme ils avaient pu faire pour les systèmes de fichier, cf. http://linuxfr.org/2006/07/23/21124.html ), est-ce qu'ils ne pourraient pas faire de même pour la hiérarchie unix, le format de packetage, et les fichiers de configuration (virez-moi ces fichiers avec des . du dossier /home svp, c'est une horreur sans nom car tous les programmes ne les filtrent pas)
Bien sûr les avis de chacun divergent, mais ne serait-il pas possible dans un premier temps d'envisager de faire tout un système "propre", et que les spécificités actuelles des diverses distributions se retrouvent via des liens symboliques ? (un peu comme dans gobolinux)
http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard
http://fr.wikipedia.org/wiki/Linux_Standard_Base
Enfin, et on pourrait en faire tout un nouveau journal, au niveau de la distribution des binaires, cela ne serait pas mal s'il y avait également un peu de standardisation. Je dois dire qu'avant je n'appréciais pas trop un système comme autopacketage, mais finalement ce n'est pas si mal, car cela permet de s'installer sur la plupart des distributions (on en revient au problème que si tout était un peu moins bordélique dans les systèmes de paquets, il n'y aurait pas besoin de système comme autopacketage... car je ne suis pas trop en faveur de binaires à télécharger et installer façon windows ou pcbsd). D'ailleurs cela serait bien si cette distribution de binaire pourrait être un peu plus généralisée par les auteurs de logiciels, sans remettre en cause la présence des sources bien entendu, c'est vraiment lourd lorsque l'on se trouve avec un petit programme à compiler qui repose sur des environnements de programmation pas très léger genre gtk, sdl, qt, clanlib etc. Pour quelqu'un qui connait un peu ça va, pour un autre, il va découvrir la joie de la recherche des fichiers de dev, des configure qui ne passent pas (pourquoi c'est pas les grosses bibliothèques à problème qui sont testées en premier d'ailleurs, cela éviterait de tout lister pour rien ?), des make qui flanchent, et surtout du jeu de ricochet des dépendances de dépendances de dépendances...
L'autre fois pour compiler un truc "tout bête" comme ion3 sous opensuse j'ai dû mettre 1/2 heure, chaque dépendance dépendait d'une autre qui au final ne compilait pas, et j'en ai été quitte pour installer ion2 à la place...
En fait sur pas mal de projets on trouve 1 binaire windows, 1 paquet dmg binaire mac osx, et les sources pour linux (démerdez-vous, et tant pis pour les newbies). Et si on n'a pas les sources, c'est un paquet pour debian, un pour ubuntu, un pour fedora, un pour mandriva, un pour suse, un pour slackware... (cf. http://www.videolan.org/vlc/ )
C'est vraiment pas pour aider le décideur pressé tout ça...
aujourd'hui vendredi, jour propice à la discussion, quelques idées et frustrations me trottaient dans la tête.
Jusqu'à présent j'étais plutôt habitué à l'utilisation de Debian, et sans remettre en cause ceci j'ai commencé à tester d'autres distributions. C'est alors que j'ai remarqué que ce qui me semblait normal sous Debian ne l'était pas forcément ailleurs, par exemple certains programmes se retrouvent dans /usr/bin sous debian, alors qu'ailleurs ils sont installés par défaut dans /usr/local/bin, de même on peut avoir des applications graphiques dans /usr/bin, et ailleurs on les retrouve dans /usr/X11R6/bin, voire dans /opt etc. Sans vouloir défendre plus un point de vue qu'un autre, pour parler franchement est-ce qu'il n'est pas débile de faire un format de paquet par distribution, les paquets d'une distribution à l'autre ne s'échangeant pas forcément très bien ? (dépendances etc.)
Si j'ai bien compris le format .deb est arrivé le premier (cf. wikipedia à propos du Linux Standard Base), puis .rpm, mais d'une distribution à l'autre, les rpm ne sont pas forcément compatibles. Donc on a des rpm spécifiques à red had, fedora, d'autres à mandriva, opensuse, des deb spécifiques à debian, d'autres à ubuntu (pourquoi n'ont-ils pas sorti des .ubu à la place ?), et puis des tgz pour slackware, et si on peut convertir de l'un à l'autre avec la commande alien (de deb à rpm et vice versa), d'une distribution rpm à l'autre c'est plutôt hasardeux, pour ce que j'ai vu (et idem de debian à ubuntu)
J'ai trouvé aussi qu'il existait un genre de consortium Filesystem Hierarchy Standard, mais que cela n'avait pas été respecté non plus.
Il en va de même pour les fichiers de configuration, et tout cela contribue à faire un joyeu bordel pour qui veut s'y retrouver un peu. Alors on va dire que c'est la diversité qui fait la force du libre, mais je trouve dommage (j'ai écrit "débile" plus haut) que les efforts des empaqueteurs soient dispersé à cause de cela. Si quelqu'un passe (qui a dit perd ?) du temps à empaqueter pour Debian, son travail ne sera pas utile pour ceux qui utilisent opensuse ou fedora, etc. Même s'il existe des outils comme smart install, ce n'est pas la panacée non plus, et le système linux me semble un peu affaibli par cet éclatement.
Alors parfois les acteurs des solutions Unix arrivent à s'entendre pour avancer (comme ils avaient pu faire pour les systèmes de fichier, cf. http://linuxfr.org/2006/07/23/21124.html ), est-ce qu'ils ne pourraient pas faire de même pour la hiérarchie unix, le format de packetage, et les fichiers de configuration (virez-moi ces fichiers avec des . du dossier /home svp, c'est une horreur sans nom car tous les programmes ne les filtrent pas)
Bien sûr les avis de chacun divergent, mais ne serait-il pas possible dans un premier temps d'envisager de faire tout un système "propre", et que les spécificités actuelles des diverses distributions se retrouvent via des liens symboliques ? (un peu comme dans gobolinux)
http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard
http://fr.wikipedia.org/wiki/Linux_Standard_Base
Enfin, et on pourrait en faire tout un nouveau journal, au niveau de la distribution des binaires, cela ne serait pas mal s'il y avait également un peu de standardisation. Je dois dire qu'avant je n'appréciais pas trop un système comme autopacketage, mais finalement ce n'est pas si mal, car cela permet de s'installer sur la plupart des distributions (on en revient au problème que si tout était un peu moins bordélique dans les systèmes de paquets, il n'y aurait pas besoin de système comme autopacketage... car je ne suis pas trop en faveur de binaires à télécharger et installer façon windows ou pcbsd). D'ailleurs cela serait bien si cette distribution de binaire pourrait être un peu plus généralisée par les auteurs de logiciels, sans remettre en cause la présence des sources bien entendu, c'est vraiment lourd lorsque l'on se trouve avec un petit programme à compiler qui repose sur des environnements de programmation pas très léger genre gtk, sdl, qt, clanlib etc. Pour quelqu'un qui connait un peu ça va, pour un autre, il va découvrir la joie de la recherche des fichiers de dev, des configure qui ne passent pas (pourquoi c'est pas les grosses bibliothèques à problème qui sont testées en premier d'ailleurs, cela éviterait de tout lister pour rien ?), des make qui flanchent, et surtout du jeu de ricochet des dépendances de dépendances de dépendances...
L'autre fois pour compiler un truc "tout bête" comme ion3 sous opensuse j'ai dû mettre 1/2 heure, chaque dépendance dépendait d'une autre qui au final ne compilait pas, et j'en ai été quitte pour installer ion2 à la place...
En fait sur pas mal de projets on trouve 1 binaire windows, 1 paquet dmg binaire mac osx, et les sources pour linux (démerdez-vous, et tant pis pour les newbies). Et si on n'a pas les sources, c'est un paquet pour debian, un pour ubuntu, un pour fedora, un pour mandriva, un pour suse, un pour slackware... (cf. http://www.videolan.org/vlc/ )
C'est vraiment pas pour aider le décideur pressé tout ça...
> Lire le journal (121 commentaires, moyenne: 2,4).
Vous avez demandé le commentaire #769495.
Run by 
Cette page a été générée par Templeet en 0.0424s (dont 0.0049 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
pas un gestionnaire de paquet identique, mais une structure peut-etre ?
J'ai lu avec beaucoup d'interet ce journal. Je partage certains point, d'autre me gènes plus.
Pour moi le répertoire Desktop est une plaie. J'utilise xfce 4.2, et avoir ce répertoire rime à rien (a part pour autostart, donc c'est pas forcement interressant comme arborescence).
Pour la partie paquet. Je pense pas que l'élaboration dun gestionnaire de paquet unique soit interressant ou réalisable. Car dans ce cas quid des différentes politiques des distributions ? Je préfère plutot une armonisation dans les paquets. Chacun utilise son gestionnaire de paquet, mais la structure d'un paquet à l'autre est similaire. De ce fait on pourrait reprendre rapidement adapter un paquet d'une distrib en un paquet pour une autre. Mais ce modèle dépend aussi du bien vouloir des développeurs d'application.
Ce système me semblerai d'ailleurs plus facile à réaliser aujourd'hui.
Ce système serait aussi plus indépendant des différentes bibliothèques ( et compilateurs) utilisées. Donc respect du choix des développeurs de distribs.
Pour le manque de paquets de versions dev ou beta, c'est vraie que la réactivité n'est pas la même selon l'application. Pour moi à ce niveau, la seule solution c'est augmenter le nombre de personnes qui assurent le packaging. Peut-être qu'on peut écrire un outils permettant de générer l'ensemble des paquets ?
Et enfin, pour les fichiers de conf, je suis assez d'accord que tout dans la ~ n'est pas forcément le top. Un répertoire .config contenant l'ensemble des fichiers de conf des applis serait un plus (mais pas une base de registre comme il en a été question à une époque).
Voila, désolé pour la longueur mais je trouve le sujet très interressant.
[^]Re: pas un gestionnaire de paquet identique, mais une structure peut-etr
oui, voilà, je pense tout à fait ainsi :
après, cela pourrait être un genre de moulinette qui génère automatiquement les paquets en fonction de la distribution (bibliothèques dépendantes etc), comme cela le travail d'empaquetage sera fait seulement une seule fois.
Il existe checkinstall qui fonctionne pas trop mal, mais je pense que cela ne fait pas des paquets super propres, en tout cas cela dépanne très bien pour des installations locales !
http://www.trustonme.net/didactels/117.html
Tous ensemble contre l'esclavitude des logiciels privateurs !