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 #769502.
Run by 
Cette page a été générée par Templeet en 0.0667s (dont 0.0077 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
La solution ...
... Autopackage !
http://autopackage.org/
[^]Re: La solution ? Pas vraiment...
http://autopackage.org/faq.html
Donc non, autopackage n'est pas la solution.
[^]Re: La solution ? Pas vraiment...
Ce n'est pas parce que ce n'est pas LA solution que ce n'est pas UNE solution.
Le problème et les besoins sont très variés, il n'y a pas de solution unique. En tous les cas, le système de packaging des distros à montré ses qualités mais aussi ses limites et il est temps que les projets fournissent des binaires cross / distro installable par des non informaticiens. D'après moi, sans cela, GNU/Linux ne pourra pas progresser sur le desktop grand public.
http://gcompris.net logiciel educatif libre pour les enfants
[^]Re: La solution ? Pas vraiment...
Sans déc !?
Le système de package sous linux et la manière d'installer des applications (et de mettre à jour TOUT le système) est probablement ce qui impressionne le plus ceux qui ne connaissent pas Linux et est une des principales qualité du système. Evidemment, ce serait mieux qu'un seul système, parfait, émmerge.
Ce que je trouve le plus étonnant à ce sujet c'est comment, après toutes ces années (de packages) des grosses distros comme opensuse arrivent à sortir des systèmes pourris (lors de la release)
L'autre chose qui m'étonne c'est à quel point, un système de package qui me semblait assez vieillot, apt/dpkg, est rapide et fonctionne bien. Je trouve les système à base d'RPM plus lent, et sur gentoo, même avec des paquets binaires, emerge est lamentablement lent.
Bon en attendant, en utilisant debian/ubuntu on a accès à, je pense, plus de 95% de tous ce qui existe sous linux en package.
[^]Re: La solution ? Pas vraiment...
Sous Gentoo, emerge ne tient pas seulement compte des dépendances explicites des paquets, il les reconstruit à partir des choix de compilation pour chaque paquet (car ces choix peuvent changer entre 2 appels).
Et ça, aucun autre gestionnaire de paquets n'est capable de le faire.
[^]Re: La solution ? Pas vraiment...
Oui mais du coup, ça met 20 plombes... Super, t'as gagné 1 mo en tout !
[^]Re: La solution ? Pas vraiment...
Non emerge est lent tout court... C'est son design qui le rendrait lent. Deux projets en cours tente de réécrire un gestionnaire pour remplacer l'actuel portage, et c'est beaucoup, beaucoup plus rapide que emerge, l'un paludis (en c++) : http://paludis.berlios.de l'autre : pkgcore (en python comme portage) : http://dev.gentooexperimental.org/pkgcore-trac
[^]Re: La solution ? Pas vraiment...
Tu parles de rapidité du sytème de paquet. Je suppose que tu penses à la vitesse d'installation. Moi ce qui m'importe c'est le temps entre la release d'un projet et sa disponibilité dans le système de paquet. Et là, franchement on est très mauvais.
Pour le cas de GCompris, seules quelques distributions mettent à jour régulièrement et rapidement. Pour les autres, c'est au coup par coup en fonction de la disponibilité d'un packageur.
Mais attention, il y a très peut de backport, c'est à dire que pour utiliser la dernière version de GCompris, les utilisateurs doivent aussi utiliser la dernière version de leur distribution. Pour nous ce n'est pas un problème mais les utilisateurs non geek non ni l'envie, ni les conpétences pour mettre à jour leur distro et résoudre tous les petits problème qui peuvent arriver.
C'est pour cela qu'une version étendue aux librairies graphique du LSB est une nécssité. Ainsi les développeurs pourrait cibler une version du LSB plutot que les librairies installés dans leur distro au moment du développement.
L'autre problème important c'est les version BETA des projets qui ne sont pas packagé. Ce qui signifie que seul les développeurs, ceux qui savent compiler peuvent tester les logiciels. C'est vraiment pas terrible. Dans mon cas, les utilisateurs sont des professeurs, heuresement certains ont cette compétence et peuvent remonter les problèmes. Pour aller plus loin sur le poste client, il est indispensable que n'importe qui puisse installer n'importe quelle version d'un logiciel, BETA ou pas.
http://gcompris.net logiciel educatif libre pour les enfants
[^]Re: La solution ? Pas vraiment...
Il me semble que les versions beta, ce soit un des buts de "klik" ou autopackage ou 0conf (enfin j'en ai plus entendu parlé pour klik), ce qui en plus de ne pas foutre le bordel avec le paquet correspondant en stable
[^]Re: Une solution ... AUTOPACKAGE
Pour en remettre une couche.
J'avais fait un post en janvier dernier en ce sens !
http://www.linuxfr.org/comments/666470,1.html
Ce que je trouve intolérable et pas du tout productif, c'est d'avoir aujourd'hui, un super jeu (Frozen-Bubble 2) qui vient de sortir et de devoir le compiler car les binaire ne sont que pour mandriva et non pas pour debian, fedora et opensuse (ma distribution).
Lorsqu'il y aura des binaires pour windows, ça sera pour toutes les versions... Alors si vous trouvez ça normal, Linux ne pourra pas s'implanter auprès d'un large public car trop compliqué !
Dans ce cas précis où le jeu n'a rien à voir avec le système, je pense que AutoPackage est une très très bonne solution. Certes, une centralisation des logiciels installés sur le système doit être possible (rpm et autopackage) afin d'assurer la maintenance. Une idée serait d'avoir une notification lorsque le logiciel est disponible en version rpm afin d'assurer un passage autopackage->rpm
Bref, il y a des progrès à faire afin de disposer de logiciels qui viennent juste de sortir parce que sous windows, c'est vraiment plus simple...
JP Martin sous OpenSuSE 10.1/kde3.5.1
NB : super le correcteur orthographique sous firefox 2
[^]Re: Une solution ... AUTOPACKAGE
Bref, il y a des progrès à faire afin de disposer de logiciels qui viennent juste de sortir parce que sous windows, c'est vraiment plus simple...
mais mais mais...
tu veux bien attendre 5 MINUTES que quelqu'un fasse le sale boulot à ta place, que ça soit l'auteur du soft, le(s) packageur(s) de ta distribution, des tiers qui font des rpm ou autres .deb dans leur coin pour ta distrib à toi, ou encore une organisation à la Klik ou Autopackage...
parce que même si ces derniers finissent par devenir d'usage répandu, si personne n'a encore fait de paquet pour eux, il te faudra toujours attendre que quelqu'un le fasse, ou le faire toi-même.
ah, tu vas me dire, ça serait plutôt à l'auteur de le faire ? comme ça il n'aurait qu'une seule cible à générer au lieu de 5 ou plus ?
en effet c'est une possibilité, il se trouve juste qu'ils ont déjà souvent beaucoup de boulot et qu'ils ne sont pas forcément experts Autopackage. alors peut-être si vraiment ça devient d'usage courant, oui, ça deviendra aussi évident que fournir des copies d'écran, mais d'ici là demander à chaque petit projet d'être un early adopter ?
est-ce à eux de résoudre ce problème d'oeuf et de la poule, d'atteindre une masse critique, alors que c'est le problème d'autres personnes ? il va falloir faire plus que leur dire "Autopackage cai bien", par exemple leur faire un beau paquet autopackage de référence bien propre de leur projet pour leur économiser 90 % du boulot de compréhension - de formation ! - à Autopackage.
(on va passer sous silence qu'il y a déjà 3 ou 4 systèmes équivallents à Autopackage et qu'en fait tu auras aussi les gens sous Mac à gérer, les gens sous PC mais avec un système 64 bits, les gens sous ARM pour les pda...)
retour à la case départ ?
Windows has no users. It has hostages.
[^]Re: Une solution ... AUTOPACKAGE
Comme si, sous Windows, c'était vraiment plus simple d'installer un logiciel qui a déjà été empaquetté par un tiers, que ce soit l'auteur lui-même ou quelqu'un d'autre...
Sous Windows aussi, il faut d'abord compiler le logiciel puis en faire un exécutable et ce sont pas les méthodes qui manquent, pas plus que dans le monde du logiciel libre : il existe même des solutions libres pour ce faire !
En outre, les « .exe » ne sont même pas le format « standard », s'il y en a, de Microsoft pour distribuer des logiciels car ils préfèrent utiliser des « .msi ». L'apparente simplicité de Windows cache un réel bourbier.
[^]Re: Une solution ... AUTOPACKAGE
Sous windows, les logiciels tiers sont plus ou moins bien livrés quand même. Essayez d'utiliser correctement votre windows (c'est a dire sans etre admin ni meme user avec pouvoir), et d'un seul coup la quasi totalité des logiciels merdoient. C'est souvent pas grave, des droits a placer sur des clefs de base de registre ou sur un repertoire NTFS, ...
mais pas mal de soft exigent que l'utilisateur puisse ecrire dans "program files". De plus les soft ne peuvent pas vérifier de dépendances et viennent donc avec leur copie de librairie installée dans son coin a lui. Résultat, impossible de garantir que la faille de sécu liée a la librairie zip.dll est bien corrigée vu qu'on en a plusieur versions sur le système installées de partout.
On est loin, très loin de ce que réalisent les packageurs sous linux.
Autre point de vue, il est bien plus simple de creer des installeurs pour un seul OS (windows) que pour tous les OS linux. Ce serai bien que les packages marchent sur tous les OS linux, mais pourquoi pas sur les BSD aussi et les MAC OS X ? Il n'y a pas un OS linux, mais il y a autant d'OS que de distributions basées sur le kernel linux. Pensez-vous que les logiciels d'aujourd'hui s'installent sur les windows NT4 ou 98 ? ben non, ça ne marche plus, a cause des dépendances ...