Articles : Amélioration en vue pour l'installation de logiciel sur GNU/Linux.
Posté par Bruno Coudoin (page perso, ). Modéré le 04 janvier 2007.
Les systèmes de gestion de paquet que nous trouvons couramment dans nos distributions - comme apt-get ou urpmi - ont certes de nombreux avantages mais aussi des limitations. Il n'est par exemple pas simple d'avoir les dernières versions des logiciels et on se retrouve limité à la sélection des paquets de sa distribution ; or aucune ne propose l'ensemble des Logiciels Libres existants.
La nécessité de fournir des paquets binaires multi-distribution est encore plus demandée par les éditeurs de logiciels propriétaires désireux de fournir une version GNU/Linux.
Partant de ce constat, un groupe de travail a été formé au niveau du projet LSB (Linux Standard Base) et de son organisation parente le FSG (Free Standard Group) afin de rendre la vie plus facile aux utilisateurs et aux développeurs.
![[en]](../images/en.png)
Un article plus complet: (683 hits)-
Le projet LSB (227 hits)
-
Packaging Workgroup (208 hits)
-
LSB packaging mailing list. (91 hits)
![[fr]](../images/fr.png)
La LSB sur wikipedia (779 hits)
> Lire la dépêche (326 commentaires, moyenne: 2,8).
Vous avez demandé le commentaire #790489.
Run by 
Cette page a été générée par Templeet en 0.0768s (dont 0.008 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Faux problèmes à mon sens.
Je crois que c'est un peu 'politique marketing' car il y a un moyen de faire des binaires multi-plateforme : c'est de compiler en static et de fournir les libs dans un bon gros .tgz
De nombreux jeux le font (par exemple http://www.landes-eternelles.com ) avec des binaires linux. D'autres 'gros'jeux ont été annoncés ici même avec des binaires universels) des petis émulateurs sortis il y a 3-5 ans et fournis en binaires fonctionnent encore, Openoffice, firefox, etc.... il y a autopackage .. (comment fait skype ou nero ?)
Mainenant que certains veulent se faire mousser en révolutionnant encore une fois de plus le bouzin peut amener amélioration par effets de bords, mais ce n'est pas le désert non plus et ce ne sont pas des sauveurs du monde de l'univers.
Ce que j'en voie avec ma mauvaise fois trollesque légendaires, c'est un moyen pour LSB (et ses principaux promoteurs) de 'reprendre un peu le devant de la scène' dans un univers linux libre qui s'éclate sous l'effet d'un nombre croissant de distributions communiquantes, et de positionnement, face au respect de la gpl, parfois divergents.
Il est clair que les logiciels proprios qui veulent canibaliser le libre (prime au premier entrant) sont les premiers interessés d'une initiative comme cela. Par effet de 'renommé' ce groupe de travail communiquerait (peut être avec raison, question de goûts) facilement sur les grosses boites proprios qui porteraient des applis proprios sous linux, ce qui fragiliserait un peu le délicat écosystème (dans le sens économique) du libre.
Maintenant je ne pense pas que cela n'apportera rien, mais je ne pense pas non plus que cela apportera plus que la sortie du dernier wormux ou de j'enveuxpas.
Effectivement cela pourrait sembler permettre aux 'petits' de plus facilement de distribuer des package tout prêts, mais plutôt que
-de réinventer la roue
- aller à l'encontre de la philosophie linux, et aller vers un système windows clicliclic.exe fini
- aller vers un moyens de standardiser le linux de base et donc le rendre plus sensible aux virus car 'génétiquement' plus proches les uns des autres ave une api exprès pour installer sur toutes les machines
- donner aux distributions un point de fixation supplémentaire [ le driver graphique proprio nouvelle version qu'il faut attendre ET la nouvelle version du packageur miracle)
....il serait plus judiceux de mettre en place des 'fermes de compilation' pour préparer les binaires facilement.
Par exemple ce qui pourrait être le plus smart dans mes fantasmes les plus torrides : Chaque destribution founirait un ou plusieurs machine de compilation. En tant qu'utilisateur, je choisie un logiciel Lambda. Je me connecte sur le site et je donne la config de ma machine (avec un script shell qui vérifie les versions de mes libs), le serveur fait un chroot avec les versions identiques aux miennes et lance la compilation, fait le package et me distribue le package (le stock pour ne pas refaire le même travail) en travaillant directement depuis les sources de l'applis. Ensuite il met ce package à dispo en téléchargement avec les infos qui vont bien. Et hop, plus de soucis de libs, plus de soucis de distribution pour les dév. On peut même penser qu'il puisse y avoir des machines qui prennent les sources et lancent une compilation sur toutes les distributions et 'centralisent' les erreurs pour faire des corrections générales. [ cela résoudrait une grande partie des soucis, laissant que les problèmes particuliers]. Comme l'utilisateur Lambda utilise une machine 'toute prête et pas tunée, cela marcherait pour 95% des cas, respecterais la philosophie linux, pas de static, compile from source etc...., et soulagerait les dev et les utilisateurs.
[^]Re: Faux problèmes à mon sens.
Tu dis que le problème est faux mais tu proposes une autre solution. Faut savoir !
Ta solution ne marchera pas. Tu peux mettre l'interface que tu veux sur make, il n'en reste pas moins que compiler est une opération qui doit être réalisée par des spécialistes. Certe quant ça marche tout va bien mais quant ça marche pas il fait quoi l'utilisateur ? Et des raissons que ça marche pas la compilation, c'est pas ça qui manque... (Déjà dit plus haut mais bon)
En plus ton système pre-suppose que tout le monde à un accés haut-débit. Quid de la distribution de logiciel en paquet binaire dans les magazine. Ce serait pourtant pratique pour beaucoup.
http://gcompris.net logiciel educatif libre pour les enfants
[^]Re: Faux problèmes à mon sens.
Quid de la distribution de logiciel en paquet binaire dans les magazine. Ce serait pourtant pratique pour beaucoup.
Qu'est ce qui empèche de le faire aujourd'hui avec un script d'install en ligne de commande ou graphique ?
C'est un faux problème.
[^]Re: Faux problèmes à mon sens.
Il faut vite prévenir Debian que buildd [1] n'a aucune chance de marcher alors... On me dit dans mon oreillette que si...
[1] http://buildd.debian.org/
[^]Re: Faux problèmes à mon sens.
Si je ne comprend bien, cet outil prend en entrée des "Debian source packages", pas des sources packages fournis directement pas le projet. Si tu préfères le travaille de packaging propre à la distribution est déjà commencé, l'utilisateur peut alors le terminer. Cela ne résoud en rien le problème.
Commen tu fais pour livrer à tes utilisateurs GNU/Linux un programme qu'ils puissent installer simplement, quelque soit leur distribution.
http://gcompris.net logiciel educatif libre pour les enfants
[^]Faut quand même pas trop pousser...
Ebfin, bon, honnêtement, il y a un certain nombre de distributions l'inux qu'on peut négliger tellement leur diffusion est confidentielle : après tout, si ces micro-distributions se démerdent pour ne même pas fournir une compatibilité avec une distribution un peu plus visible que la leur, c'est un choix de leur part.
Sinon, la question du support des versions "anciennes" (plus de 12 mois ?) de la plupart des distributions pourrait tout aussi bien se poser.
Sinon, fabriquer des packages RPMs bien binaires pour un redhat/fedora/Suse à partir de "Debian source packages" n'est normalement pas très difficile et assez direct : le choix du format source de départ est donc plutôt bien pensé, et les grandes distributions sont désormais suffisamment semblables pour qu'il y ait "peu" de problèmes imaginables avec les applis desktop intéressant typiquement l'utilisateur néophyte.
[^]Re: Faut quand même pas trop pousser...
> Ebfin, bon, honnêtement, il y a un certain nombre de distributions l'inux
> qu'on peut négliger tellement leur diffusion est confidentielle
De la même façon qu'on peut négliger les os confidentielles comme les distributions linux, d'un point de vue général.
[^]Re: Faux problèmes à mon sens.
AMHA, on n'en a probablement pas envie.
Je m'explique : avant de distribuer la toute dernière version de freeciv 3.0 par exemple, une distribution va faire faire un truc magique qui fait une grosse part de la valeur ajoutée d'une distribution : la gestion de configuration.
Elle va vérifier que la toute dernière version de Freeciv marche bien avec la libtoto-7.2.134.21434-rev2 installée, que la libtiti-2.0 est bien disponible dans son catalogue de paquets, que la nouvelle version ne casse pas tout par rapport à la précédente, etc.
Toute cette étape est perdue si on ne passe plus par la case packaging.
Un binaire universel suppose que son créateur aie fait tout ce boulot de packaging à prori et pour toutes les distributions possibles et imaginables. Quand il s'agit de 4ou 5 versions de Windows ou MacOSX je veux bien lui faire confiance, mais quand il s'agit des dizaines (centaines ?) "flavors" de systèmes GNU/Linux/*BSD/? qui peuplent le monde des systèmes libres, je préfère largement faire confiance à un packageur spécialiste de ma distribution avant de taper "sudo ./install.sh" ou "sudo make install" (vécu avec la compilation de drivers webcam qui foiraient sur Ubuntu à cause du système de sudo tandis que les cripts magiques d'easycam2 marchaient tout bien).
[^]Re: Faux problèmes à mon sens.
Commen tu fais pour livrer à tes utilisateurs GNU/Linux un programme qu'ils puissent installer simplement, quelque soit leur distribution.
comment tu fais pour le livrer à un utilisateur :
*utilisant un FreeBSD
*utilisant un Linux tournant sur un processeur PasCommun (tm)
*utilisant un Linux où il manque une librairie majeure indispensable à ton programme, pour une raison quelconque (comme... un manque de ressources ! parce que la distribution est le fruit de deux étudiants)
*utilisant une distribution obsolète, abandonnée, plus à jour... comme une Mandrake de y'a juste un an (ou à peine plus)
ne viens pas me dire "ah non ah non ! hors-jeu ! c'est débile comme cas de figure ! je parle d'utilisateurs normaux moi", tu viens d'imposer "quelque soit leur distribution", faudrait savoir...
Windows has no users. It has hostages.
[^]Re: Faux problèmes à mon sens.
Je t'accorde que ./configure; make; make install c'est pas trivial pour un utilisateur de base (le plus dur est d'ailleurs plutôt la gestion des dépendances). Et que c'est long...
Mais de là à dire
Je ne vois pas bien en quoi compiler est une opération qui doit être réalisée par des spécialistes. Ça peut être automatisé (et la construction des paquets binaires l'est pour pas mal de distrib)... Et quand ça marche pas avec une install binaire, il fait quoi l'utilisateur ? Le rapport de bug (et la correction) sont souvent plus facile quand on sait à quelle ligne ça a foiré...
[^]Re: Faux problèmes à mon sens.
Quand on sait qui est le principal instigateur (et « CTO » du LSB) de cette initiative, on comprend mieux : Ian Murdock.
Quand on voit quels sont les principaux acteurs (Progeny, RedHat et Novell), on comprend également mieux pourquoi il y aurait intérêt à créer un tel système afin de permettre une installation plus aisée des logiciels, fussent-ils propriétaires.
[^]Re: Faux problèmes à mon sens.
le serveur fait un chroot avec les versions identiques aux miennes et lance la compilation, fait le package et me distribue le package
Pas mal comme idée mais à la sortie du dernier Froozenbubble ou Wormux que tu cites, j'imagine la bande passante du serveur.
Et le pauvre mainteneur, il fait comment pour refroidir son petit serveur qui doit compiler à tout va (azote liquide?)
[^]Re: Faux problèmes à mon sens.
Il pourra toujours l'inscrire à un projet de calcul distribué ;-)
[^]Re: Faux problèmes à mon sens.
C'est pas tant la bande passante mais surtout le CPU qui va limiter. Si tu veut télécharger un logiciel "moyen" qui prend 10 minutes à compiler sur un PC "normal", et qu'il y'a 10 autres personnes qui le veulent en même temps que toi, tu vas devoir attendre (grosso modo) 2 heures avant que ton paquet ne soit près !
Avantage du paquet binaire, une seul machine se tape les 10 minutes de compilation. Pour un utilisateur lambda, c'est pratique, rapide, et écologique en plus : 1 million de personne qui compilent 10 minutes = 19 années de CPU "économisées" (au profit de l'environnement, ou de BOINC).
[^]Re: Faux problèmes à mon sens.
> il y a un moyen de faire des binaires multi-plateforme : c'est de compiler en static et de fournir les libs dans un bon gros .tgz
Et donc ça implique que les éditeurs qui distribuent le bon gros tgz le mettent à jour dès qu'une faille de sécu dans une de leur dépendance a été trouvée (libpng, openssl, ...). Ou pas, et alors c'est la fete du slip
[^]Re: Faux problèmes à mon sens.
oui, ou alors, il faut faire du dynamique et gérer toutes les situations possibes : c'est la fête du string (je prefère).
Nan, il n'y a pas de solutions. Le paradigme linux c'est configure,make, make install. .. ou alors tout le monde sous la même distribution (mais la mienne alors) :-)
Sinon, ils donnent les sources et ils auront des paquets pour redhat/fedora/debian/ubuntu/suze/gentoo/slackware sans soucis en très peu de temps.
Faut pas oublier que la demande doit venir de ceux qui ne _veulent pas_ donner les sources de leurs applis, on va pas se faire chier pour leur simplifier la tache de faire du non libre quand même.