Articles précédents : Articles
- [31] Xen 3.0.4 et la virtualisation matérielle
- [21] Résultats du concours LinuxFr « Lettre au Père Noël »
- [7] Vidéos de conférences sur le logiciel libre
- [57] Framasoft mis en demeure de constater un certain manque de lucidité
- [24] Citadel, BBS aux airs de groupware, vient de sortir en version 7.0
- [34] Nokia et l'open source
- [21] Des nouvelles du DADVSI
- [114] Une plongée dans le développement de Linux
- [31] La FSF donne $60,000 pour la libération de Ryzom
- [186] L'UFC Que Choisir contre la vente liée
Liens connexes
- Un article plus complet: (684 hits)
- Le projet LSB (227 hits)
- Packaging Workgroup (208 hits)
- LSB packaging mailing list. (92 hits)
- La LSB sur wikipedia (783 hits)
Dépêche modérée par
Dépêche éditée par
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.
Un article plus complet: (684 hits)
Le projet LSB (227 hits)
Packaging Workgroup (208 hits)
LSB packaging mailing list. (92 hits)
La LSB sur wikipedia (783 hits)
> Lire la suite (326 commentaires, moyenne: 2,8). [dépêche : 1170 caractères]
L'idée de base est d'ajouter une API commune dans les différent systèmes de paquets. Cette API permettrait à un logiciel de pouvoir s'enregistrer auprès du système de paquets.
Pour ce qui est de la problématique des dépendances, un logiciel devrait venir avec tout ce qui lui est nécessaire et qui n'est pas défini par la LSB. Il serait possible d'avoir quelques cas très limités où des applications pourraient dépendre d'autres composants.
Ainsi, si un projet cible une version donnée de la LSB et qu'il existe un installeur multi-distribution, la seule contrainte pour un utilisateur sera d'avoir une distribution qui supporte cette version de la LSB.
Tout n'est pas réglé car le problème n'est pas simple. Pour ceux qui sont intéressés, le FSG a créé un groupe de travail sur le sujet et vient de relancer une liste de discussion.
[+] Beurk
"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."
Certes, mais doit-on réellement emmerder toute la communauté des utilisateurs de logiciels libres simplement pour faciliter l'introduction de logiciels propriétaires dans les distributions majoritaires ?
Chaque distribution est libre de faire les risettes qu'elle voudra aux ogres qu'elle voudra séduire, mais je ne vois vraiment pas l'intérêt de standardiser dans ce secteur.
Bonne chance à ceux qui essaieront : ils ne seront pas les premiers, ils ne seront sans doute pas les derniers.
Au fait, Java, c'était pas sensé servir à ça aussi ?
-
[^]Re: Beurk
Posté par Bruno Coudoin (page perso, ) le 04/01/2007 à 09:46. (lien). Évalué à 10.Le problème c'est qu'en embétant les logiciels propriètaire, on rend aussi la vie difficile aux utilisateurs de Logiciel Libres.
Tu prend un logiciel, genre un jeu libre annoncé ici même. Il faut combien de temps avant de l'avoir dans les distros ? Il se passe des mois, voir des années.
Donc bien sur tu t'en fou, probablement que tu compiles mais ici on parle bien d'utilisateur personnels qui n'ont ni l'envie, ni les compétences pour compiler.
Donc contrairement à ce qu'on pense généralement, ce problème d'installation de logiciel sur GNU/Linux concerne aussi les Logiciels Libres.--
http://gcompris.net logiciel educatif libre pour les enfants-
[^]Re: Beurk
Posté par Grumbl (page perso, ) le 04/01/2007 à 10:02. (lien). Évalué à 1.Je ne vois pas en quoi le fait de changer de format de paquetage binaire réduira le temps requis pour le réaliser ? Si personne ne veut faire le paquetage, le packetage ne sera pas fait. Dans le cas contraire, tout RPM est facilement adaptable sur la plupart des distributions essentiellement binaires, généralement basées sur RPM.
Qui plus est, il ne faut pas avoir la mémoire courte : s'il existe autant de logiques de paquetages binaires que de distributions, c'est bien parce que, depuis que les distributions Linux à base de binaires existent, chacune d'elle, qu'il s'agisse de Redhat avec RPM (à l'origine du moins); de SuSE avec YAST ou de Mandriva avec ses trucs plus ou moins compatibles Redhat au débat et puis finalement non après ont essayé d'enfermer une partie des utilisateurs dans ses propres mécanismes.-
[^]Re: Beurk
Posté par Bruno Coudoin (page perso, ) le 04/01/2007 à 10:28. (lien). Évalué à 10.En général les projets ne demandent pas mieux que de fournir des paquets binaires en plus de leur tarball. Sur windows, sur mac, c'est facile mais sur windows tu fais comment. Pour un petit projet c'est très compliqué que de fournir un paquet binaire ne serait-ce que pour les 5 distros les plus courantes.
On en arrive à la situation absurde ou il est plus simple d'installer un Logiciel Libre sur une plate-forme propriétaire que sur GNU/Linux, alors que c'est la plate-forme des développeurs !--
http://gcompris.net logiciel educatif libre pour les enfants-
[^]Re: Beurk
Posté par Frédéric Lopez () le 04/01/2007 à 11:42. (lien). Évalué à 6.En général les projets ne demandent pas mieux que de fournir des paquets binaires en plus de leur tarball.
Ben il suffit d'utiliser loki_setup (http://icculus.org/loki_setup/ ) jusqu'à ce que le projet devienne tellement intéressant que des volontaires se proposent pour créer des paquets.
C'est ce qu'utilisent les éditeurs propriétaires sous Linux (Loki, id Software, Nvidia, Epic, Google, etc.) et ça marche sur pas mal de plates-formes (tous les Linux, FreeBSD, AIX, HP-UX, IRIX, SunOS/Solaris, Mac OS X, etc.).
-
[^]Re: Beurk
Posté par Grumbl (page perso, ) le 04/01/2007 à 12:14. (lien). Évalué à 4.Une remarque : Firefox (les releases precoces, s'entend), Java, Flash-Téhème, etc, arrivent très bien à faire des paquetages binaires installables sur la plupart des distributions sans aller chercher à implanter leur gestionnaire de paquetages binaires à eux sur quelque distro que ce soit. Généralement, il suffit de compiler statiquement avec tout ce qui pourrait poser problème : c'est laid, mais ça marche. Mais il est vrai que la liberté qu'offre Windows à l'utilisateur de jouer à l'insu de son plein gré avec les librairies ne sera probablement pas atteignable avec un nunux.
Ceci dit, si, concrètement, un auteur sympa de logiciels libres a du mal à réaliser un paquetage pour une dustribution donnée, ce qui se comprend tout à fait, ne pas hésiter à faire passer une petite annonce sur linuxfr (ou, au pire, s'adresser aux usual suspects, comme par exemple Mathias Saou de http://freshrpms.net/ pour Redhat/Fedora)
-
[^]Re: Beurk
Posté par Gniarf () le 04/01/2007 à 14:56. (lien). Évalué à 9.tu n'as toujours pas compris le coeur du problème depuis http://linuxfr.org/~Zezinho/23367.html
si l'auteur du projet/logiciel Bidule n'a PAS LE TEMPS ou SE FOUT de proposer des binaires plus ou moins prêts à l'emploi et si personne d'autre ne le fait à sa place, oui, il pourra rester "en souffrance" des années. et ça ne sert à rien de lui dire "mais utilise donc le format de paquets universel ABC" puisqu'il n'a déjà PAS LE TEMPS de le faire ou S'EN FOUT.
tu as l'air de poser comme une évidence que c'est au développeur de faire ce sale boulot. soit. ce n'est peut-être pas son avis, ou alors il se fout - tout simplement - que monsieur ToutLeMonde ne puisse pas installer simplement son soft : les gens qui l'interessent y arrivent, il est content comme ça. les autres sont priés d'aller demander des paquets à leur distribution chérie, il estime qu'il a fini son boulot, il a une vie, tout ça.
oui, ça peut surprendre, oui, ça peut choquer, mais c'est comme ça. les distributions règlent effectivement parfois directement ou indirectement (sections "contrib") le problème, mais pas toujours, certes.
l'utilisateur final pleurniche ? la belle affaire, visiblement il ne sait faire que ça d'ailleurs. s'il veut que quelqu'un lui fasse un joli paquet cadeau de tel ou tel soft, et que l'auteur ne le fait pas, il pourra pleurnicher encore longtemps, ça ne va pas changer grand chose.
tu pleurniches que l'utilisateur final pleurniche ? au boulot, bonhomme ! toi tu peux faire quelque chose. et si tu ne veux pas mettre la main à la pâte parce que EVIDEMMENT que c'est à l'auteur de le faire, je ne vois plus trop bien ce qui t'autorise à râler ainsi.--
Windows has no users. It has hostages.-
[^]Re: Beurk
Posté par Thomas Douillard () le 04/01/2007 à 15:33. (lien). Évalué à 2.En même temps si le truc s'intègre dans les autotools par exemple ça devient tout de suite plus simple.
-
[^]Re: Beurk
Posté par Troy McClure (page perso, ) le 04/01/2007 à 16:50. (lien). Évalué à 10.on voit rarement le mot "simple" associé avec les autotools :) alors que "bloatted","illisible" et "sux" ça revient beaucoup plus souvent
-
[^]Re: Beurk
Posté par Mildred (Jabber id, page perso, ) le 07/01/2007 à 11:07. (lien). Évalué à 2.Pour autoconf, pourquoi pas, mais automake je ne pense pas.
-
-
[^]Re: Beurk
Posté par Bruno Coudoin (page perso, ) le 04/01/2007 à 17:48. (lien). Évalué à 4.Tu n'as pas compris que si certains projet Libre ne fournissent pas de paquets binaires pret à l'emploi c'est parce-qu'il n'y a pas de solution simple sur la plate-forme GNU/Linux pour faire ça.
Si c'était simple à faire, et que ça marche bien tous les projets le ferait.--
http://gcompris.net logiciel educatif libre pour les enfants-
[^]Re: Beurk
Posté par Raphaël SurcouF (Jabber id, page perso, ) le 04/01/2007 à 17:54. (lien). Évalué à 0.Pas de solutions simples ? Qu'est-ce qu'il ne faut pas entendre...
-
[^]Re: Beurk
Posté par Grumbl (page perso, ) le 04/01/2007 à 18:00. (lien). Évalué à 2.Ceci dit, abus de tutoriaux nuit rarement.
-
-
[^]Re: Beurk
Posté par Gniarf () le 06/01/2007 à 03:54. (lien). Évalué à 1.Tu n'as pas compris que si certains projet Libre ne fournissent pas de paquets binaires pret à l'emploi c'est parce-qu'il n'y a pas de solution simple sur la plate-forme GNU/Linux pour faire ça.
je vais t'aider :
s'ils ne le font pas, c'est qu'ils ne le peuvent pas, ou bien encore qu'ils ne le veulent pas.
je te rassure, il n'y a pas de solution compliquée^Wévoluée non plus qui puisse marcher. tout ce que klik et autres arriveront à faire c'est se transformer en solutions de distributions de logiciels prêts à l'emploi, comme Cygwin sous Windows, une distribution dans le système. ce n'est pas une totale idiotie, mais il y a des désavantages aussi et des problèmes prévisibles dès maintenant.
et d'ailleurs tu sais très bien que les éditeurs de logiciels propriétaires arrivent à faire des bidules binaires prèts à l'emploi et qu'en fait ça se révèle être de la poudre aux yeux si tu grattes un peu le vernis de la réalité : là tu vois en fait que non, tu as des contraintes et des prérequis et que si ton Linux est un peu trop vieux il vaudra mieux en installer un plus récent sans trop chercher à comprendre. bouh ! pourtant eux ont les ressources qu'il faut. que passa ?
Si c'était simple à faire, et que ça marche bien tous les projets le ferait.
non. c'est un voeux pieux, ça, une prospective indigne de toi. et ce n'est même pas dit qu'ils trouvent que ça soit une bonne idée, tout simplement.
d'ailleurs j'ai dit "pieux". tu as remarqué qu'il y a plusieurs religions du Verbe ici bas ? une seule ça serait plus pratique, je ne comprends pas pourquoi ces cons ne se mettent pas d'accord pour avoir une base commune avec des rites standardisés au maximum entre les trois religions et harmoniser, rendre compatibles leurs croyances, on économiserait sûrement beaucoup de papier en ayant un seul livre saint au lieu de trois. enfin bon, pour commencer il faudrait qu'on se mette tous à l'esperanto...
pour commencer il faudrait faire le tour de tous les projets similaires, klik, autopackage et tous les autres. en choisir un au hasard et réunir les têtes pensantes de tous les autres dans une salle et balancer une grenade dedans. boum !
parce que dans le genre "efforts dupliqués", ça pourrait être très marrant aussi : si une nouvelle version plus complète et pas trop bancale de la LSB sort (parce que Alan Cox avait ralé sur une version précédente, entre autres), et que tu te retrouves avec une demi-douzaine d'initiatives similiaires dans le genre de klik ou autopackage et que rien ne les distingue vraiment en terme de popularité ou de fonctionnalités, laquelle, toi développeur isolé, vas-tu choisir et donc soutenir ? et tous les autres projets vont faire le même choix que toi ?
si tu crois qu'ils ne sont pas assez bêtes pour en arriver à ce genre de désastres pour des bêtes raisons de conflits internes, de politiques, de c'est moi le chef, de ta solution elle pue, de on n'a pas les mêmes objectifs donc deux projets c'est viable, tu te trompes lourdement.--
Windows has no users. It has hostages.
-
-
-
[^]Re: Beurk
Posté par Guillaume Rousse (page perso, ) le 04/01/2007 à 15:42. (lien). Évalué à 10.> On en arrive à la situation absurde ou il est plus simple d'installer un Logiciel Libre sur une plate-forme propriétaire que sur GNU/Linux, alors que c'est la plate-forme des développeurs !
Sauf que la plate-forme propriétaire (windows) n'existe qu'avec 6 variations possibles (95, 98, 2000, ME, XP, Vista), avec une ABI relativement homogène et une compatibilité ascendante marquée.
Tu retires toutes les distributions du monde sauf redhat, tu vires de celle-ci tous les noyaux sauf celui de base (et tu empeches bien sur de recompiler le sien), et tu auras une situation a peu près comparable...
C'est la diversité le problème ici. Pas un seul producteur de logiciel ne peut gérer l'ensemble de la diversité des cibles Linux à lui seul (ou alors il faut faire plein de compromis, genre compilation statique par exemple). L'ensemble du système est basé sur une distribution des taches entre les producteurs de logicels, et les intégrateurs finaux qui publient les distributions. Quand les premiers cherchent à faire le travail des seconds, par exemple parce qu'ils refusent le droit de redistribuer a des tiers (cas des logiciels propriétaires), on aboutit a des résultats au mieux médiocre, au pire non-fonctionnels.-
[^]Re: Beurk
-
[^]Re: Beurk
Posté par Mark Havel () le 04/01/2007 à 16:40. (lien). Évalué à 3.En même temps pour continuer à utiliser des Windows 9x, il faut vraiment être un peu maso ou obligé de nos jours...
-
[^]Re: Beurk
Posté par Nicolas Schoonbroodt (Jabber id, page perso, ) le 04/01/2007 à 18:41. (lien). Évalué à 7.s/9x//
--
[ Répondre ] Ce commentaire est-il impertinent ou utile ?
-
[^]Re: Beurk
Posté par Grumbl (page perso, ) le 04/01/2007 à 19:52. (lien). Évalué à 2.W9x ça marche super bien dans un émulateur ou sur un P166 : ideal pour les vieux jeux (ou pour tester des logiciels en environnement jetable). C'est presque un système léger de nos jours.
-
-
[^]Re: Beurk
Posté par Bruno Coudoin (page perso, ) le 04/01/2007 à 17:14. (lien). Évalué à 6.Tu fais une bonne analyse de la situation, c'est la diversité qui pose problème. Il existe deux solutions :
- on attend que le 'marché' décide et qu'une seule distribution devienne omnipotante. Tous le monde package pour celle là seulement les autres se retrouvent marginalisées. Ce n'est pas vraiment ce qui ce passe et ce n'est pas de mon point de vue souhaitable. La diversité c'est aussi notre richesse.
- on définit une plate-forme logiciel que toutes les distributions auront à minima. Ensuite les projets peuvent cibler cette version et fournir un binaire qui s'installe partout. Rien n'empeche chaque distribution d'évoluer, d'innover, de faire mieux mais il fait une base commune fiable et bien définie.
Par contre je ne suis pas d'accord avec toi sur le role obligatoire des tiers packageurs. C'est une option, c'est bien mais ne doit pas être un point de passage obligé, ni pour le logiciel libre, ni pour le propriétaire. Ce système à des avantages mais aussi de nombreux inconvénients qu'on cherche tous à se masquer. Un projet libre ou propriétaire doit fournir un paquet binaire prêt à être installé, quelque soit la plate-forme, c'est indispensable.--
http://gcompris.net logiciel educatif libre pour les enfants-
[^]Re: Beurk
Posté par Raphaël SurcouF (Jabber id, page perso, ) le 04/01/2007 à 17:59. (lien). Évalué à 2.Par contre je ne suis pas d'accord avec toi sur le role obligatoire des tiers packageurs. C'est une option, c'est bien mais ne doit pas être un point de passage obligé, ni pour le logiciel libre, ni pour le propriétaire. Ce système à des avantages mais aussi de nombreux inconvénients qu'on cherche tous à se masquer. Un projet libre ou propriétaire doit fournir un paquet binaire prêt à être installé, quelque soit la plate-forme, c'est indispensable.
Je suis désolé mais c'est un non-sens complet.
Tu n'es pas d'accord avec lui sur le rôle des tiers packageurs ? Donc, d'après les distributions ne servent à rien, il faudrait laisser le boulot d'installation binaires aux seuls développeurs des projets libres ?
N'est-ce pas justement par manque de temps et de personnel compétent que tu trouves la situation déplorable, alors même que tu bénéficies pour GCompris d'un support largement supérieur à la majorité des projets libres !
Un peu de décence et de cohérence ferait du bien...
Tu ne peux pas vouloir défendre la diversité quand tu demandes précisément aux éditeurs de distributions de Linux de ne faire plus qu'un ou peu s'en faut.-
[^]Re: Beurk
Posté par Bruno Coudoin (page perso, ) le 04/01/2007 à 19:41. (lien). Évalué à 5.Tu n'as pas compris ce que je veux dire. Bien sûr que les distributions sont importantes, indispensable même. Ce que je dis c'est que la distribution de logiciel à travers le système de paquet ne doit pas être la seule et unique façon de délivrer nos logiciels à nos utilisateurs.
Non ce n'est pas par manque de temps que la situation est déplorable, c'est parce que l'on a pas de solution qui permette la distribution de paquet binaire multi-distro. Au lieu de se plaindre du temps qui manque, il est bien plus efficace de mettre en place des solutions pour éviter les taches fastidieuses.
Je ne parle pas ici au nom de GCompris mais à travers mon expérience sur ce projet. J'explique en toute liberté les problèmes que je rencontre et des solutions qui me semble prometteuses. Mes arguments sont constructifs, dans l'objectif d'améliorer la plate-forme GNU/Linux, rien de plus.
La diversité c'est bien, je suis pour mais je suis aussi pour la simplicité. Ce qui est proposé par le LSB ne limite en rien les possibilités de différenciation et d'innovation des distributions, pour preuve c'est que les distributions majeures respectent déjà ce standard.--
http://gcompris.net logiciel educatif libre pour les enfants-
[^]Re: Beurk
Posté par Raphaël SurcouF (Jabber id, page perso, ) le 04/01/2007 à 23:34. (lien). Évalué à 4.Le problème est que cela semble encore à l'initiative d'Ian Murdock pour faire avancer Progeny qui ne décolle toujours pas et cela risque surtout, au vu des acteurs actuels, tourner surtout autour du format RPM sans aller voir plus loin.
Laissons leur donc le temps de travailler sur ce sujet mais j'ai bien peur qu'il ne s'agisse qu'une forme déguisée d'un vieux débat sur la compatibilité binaire contre la compatibilité source.
-
[^]Re: Beurk
Posté par Raphaël SurcouF (Jabber id, page perso, ) le 04/01/2007 à 23:40. (lien). Évalué à 1.Qu'est-ce qui t'empêche de renvoyer l'utilisateur auprès de celui qui a créé le paquet binaire, surtout s'il s'agit d'une distribution ? Voire de contacter directement le responsable en plaçant l'utilisateur en copie ?
-
-
-
-
-
[^]Re: Beurk
Posté par nimnim () le 05/01/2007 à 09:46. (lien). Évalué à 3.> En général les projets ne demandent pas mieux que de fournir des paquets
> binaires en plus de leur tarball.
En général les projets ont une vision centrée sur leur bébé, et sont prêts à massacrer le reste du système du moment que leur application fonctionne¹.
Ceux qui sont prêts à prendre le recul nécessaire à une intégration sans douleur n'ont pas de problèmes avec les écosystèmes de paquets actuels.
¹ Phénomène évident sous Windows, entrainant des coûts monstrueux tant pour les utilisateurs finaux (qui doivent réinstaller périodiquement leur système sans raison) et les entreprises (qui dépensent des sommes monstrueuses juste pour vérifier que les installeurs fournis par leur fournisseurs ne vont pas mettre le boxon sur leurs postes de travail)
-
-
[^]Re: Beurk
Posté par bubar () le 09/01/2007 à 01:44. (lien). Évalué à 1.https://www.redhat.com/archives/fedora-announce-list/2006-De(...)
pour info, urpmi ça roxe sévère
-
-
[^]Re: Beurk
Posté par hokata () le 04/01/2007 à 10:26. (lien). Évalué à 3.bien sur que compiler peut faire peur, mais si on change le mot compiler par installer c'est mieux non ?
Ce que je veux dire, c'est que la partie compilation est de plus en plus simple, le configure vérifie tout, puis make et make install. Tout est quasi transparent si le boulot est bien fait et les progs installés dans /usr/local/. Après ça marche pas à tout le temps du premier coup, et parfois ça ne marche pas. Et c'est dans ce sens qu'il faut chercher.
Je pense qu'il serait plus simple de travailler à faire des install.sh standards. Et un outil ou un script en plus du configure permettant de déterminer les librairies manquantes ainsi que leur place dans les distribs voir de les installer.
Par exemple j'ai besoin d'un truc comme libjpeg.so, bah une simple recherche sur le site de debian me permet de trouver le paquet. (J'imagine que c'est la même chose pour les autres distribs).
Après est-ce au LSB de définir ces principes, aux distributions d'offrir les outils ou à chaque développeurs de faire les leurs ?-
[^]Re: Beurk
Posté par Bruno Coudoin (page perso, ) le 04/01/2007 à 10:33. (lien). Évalué à 4.Ben voyons, on parle de grand public ici. Un compilateur n'a pas à être installé sur un PC grand public.
--
http://gcompris.net logiciel educatif libre pour les enfants-
[^]Re: Beurk
Posté par letsyl () le 04/01/2007 à 10:45. (lien). Évalué à 7.On peut aussi se retrouver avec des problèmes de dépendances : la libtrucmuche qui manque, elle même dépendante de la libmachin qui n'existe pas dans la bonne version sur ma distrib.
On en vient au final à rechercher/compiler tout un tas de bibliothèques (ça m'est récemment arrivé pour installer mumble). Je ne dis pas que c'est infaisable, mais ce n'est pas à la portée de tout le monde.
-
[^]Re: Beurk
Posté par hokata () le 04/01/2007 à 10:47. (lien). Évalué à 6.ah c'est nouveau ça ?
J'ai manqué un fondement fondamental de l'utilisation d'un PC par le grand public ?
Je croyais qu'on parlait de la transparence d'installation d'un logiciel non disponible en paquet dans une distribution.
Après que cette transparence soit effectuée à l'aide d'un compilateur, d'un aspirateur, ou d'un defibrillateur, quel est le problème ?
En quoi un "bon" install.sh est différent d'un install.exe ?-
[^]Re: Beurk
Posté par Bruno Coudoin (page perso, ) le 04/01/2007 à 11:08. (lien). Évalué à 5.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...--
http://gcompris.net logiciel educatif libre pour les enfants-
[^]Re: Beurk
Posté par Jeanuel (Jabber id, page perso, ) le 04/01/2007 à 12:17. (lien). Évalué à 7.Et puis c'est long... trop long pour par exemple, faire "juste un petit test"
-
[^]Re: Beurk
-
-
[^]Re: Beurk
Posté par Juke (Jabber id, page perso, ) le 04/01/2007 à 14:19. (lien). Évalué à 1.>Certe quant ça marche tout va bien mais quant ça marche pas il fait quoi l'utilisateur ?
Il remonte le problème au developpeur, comme il remonte le problème à sa distribution pour un paquet.-
[^]Re: Beurk
Posté par Laurent Pointal (page perso, ) le 04/01/2007 à 14:59. (lien). Évalué à 4.Non, si Ninux se "démocratise", 99,99% des utilisateurs diront "ça marche pas" et n'irons pas voir plus loin.
-
[^]Re: Beurk
Posté par Juke (Jabber id, page perso, ) le 04/01/2007 à 15:51. (lien). Évalué à 5.>Non, si Ninux se "démocratise", 99,99% des utilisateurs diront "ça marche pas" et n'irons pas voir plus loin.
Donc c'est bon alors, pas besoin de s'embeter ;)
-
[^]Re: Beurk
Posté par Gniarf () le 06/01/2007 à 22:32. (lien). Évalué à 1.bah euh qu'ils crèvent ? si mon téléphone est coupé et que je me contente d'attendre que ça marche, ça risque d'être long si c'est un incident sur la ligne parce qu'un guignol a débranché la mauvaise boucle.
--
Windows has no users. It has hostages.
-
-
[^]Re: Beurk
Posté par Raphaël SurcouF (Jabber id, page perso, ) le 04/01/2007 à 15:17. (lien). Évalué à 2.Ce serait normalement le rôle du responsable du paquet de la dite distribution de remonter le problème aux développeurs amonts s'il s'avère que le problème n'est pas propre à la distribution. Là, ce responsable est quand même mieux placer que l'utilisateur pour en déterminer la pertinence.
En outre, il suffirait que les développeurs amonts n'attendent pas que les responsables de paquets les contactent pour régler des problèmes et se pré-occupent davantage de la qualité de communication entre eux (du moins, pour ceux qui se pré-occupent déjà de leurs utilisateurs).
-
-
[^]Re: Beurk
Posté par Frederic GRAVIER () le 04/01/2007 à 14:54. (lien). Évalué à 3.Pourquoi dis tu que compiler doit etre une opération réalisée par des spécialistes?
Comme le dis hokata, quelle est la difference entre un bon install.sh et un install.exe, moi j'en vois une des difference.
La premiere, c'est une installation d'un logiciel via un intrepreteur, la seconde c'est l'instalation d'un logiciel par un executable.
La premiere solution me parait mieux adapté, tous du moins d'un point de vue philosophique, puisque sur un systeme libre il peut etre interesant de pouvoir ( l'utilisateur lambda, n'est pas olbligé) controler le traitement d'installation complétement.
Avec la solution binaire d'installation, qui arrive au meme résultat, la seulle difference reside dans le fait que personne ne sais ce qui ce passe.
Je pense donc que la compilation, si elle est réalisé par un bon script, est une solution tous au moins aussi valable que l'instalation par un package binaire.
Le problème reside plus dans le nombre de distribs differentes.
Qui a dis que l'installation etais plus facile sous l'os proprio de redmond?
Une experience sous cet os (obligé de metre un SP pour installé un anti-virus, j'install le SP, l'anti-virus s'install correctement, mais l'appli metier ne fonctionne plus).
Je dis peut etre des betisses, mais un soft libre doit etre livré avec son code source. c'est peut etre pas plus mal, si ce code source est utilisé pour installer ce logiciel.-
[^]Re: Beurk
Posté par Cali_Mero () le 05/01/2007 à 06:05. (lien). Évalué à 5.Tu ne peux pas penser ce que tu dis...
- Compiler c'est long. Très long. Beaucoup plus long qu'une installation de binaires, à volume égal de logiciel. Les gens normaux n'ont pas que ça à faire.
- La compilation peut rater pour tout un tas de raisons (parceque c'est une compilation, c'est un bouclier anti-erreurs donc c'est bien à ce niveau que les problèmes sont censés apparaître), ou même donner un binaire foireux même quand elle réussit, et l'utilisateur lambda est alors TOTALEMENT LARGUÉ sur ce qu'il faut faire pour que ça marche. Tu n'apprendras jamais à madame Michu à utiliser un débugueur...
Philosophiquement, oui, le code source est le moyen idéal de distribuer un logiciel libre. Mais se limiter à ce point de vue c'est aussi limiter l'audience potentielle du logiciel à ceux qui partagent son point de vue. Tout le contraire de l'ouverture, c'est une fermeture.--
#define MAGIC 0xdefaced /* I should've patented this number -cliph */-
[^]Re: Beurk
Posté par Gniarf () le 06/01/2007 à 23:05. (lien). Évalué à 0."chez moi ca marche, lance ce compile.sh chez toi"
(...) "ca marche pas, ca dit que lib not found"
"bah installe ton systeme comme le mien sinon on ne va pas y arriver"
"non je peux/veux pas" <--- là ! bug !
"bon ben débrouille toi je ne peux rien faire de plus"
madame Michu elle est bien gentille mais il faut bien qu'elle mette sa bécane en phase avec le reste du monde, tant mieux si c'est transparent pour elle.--
Windows has no users. It has hostages.-
[+] [^]Re: Beurk
Posté par Cali_Mero () le 07/01/2007 à 01:53. (lien). Évalué à -1.La bonne démarche dans ce cas serait plutôt de ne pas lui faire compiler quoiquecesoit (surtout si toi tu l'as déjà fait !) mais de lui donner un beau paquet bien propre que tu lui feras gentiment partager (par exemple un .deb généré les doigts dans le nez par checkinstall).
Si pour toi mettre sa bécane en phase avec le reste du monde signifie s'installer tout un environnement de développement qui mouline pendant de longues minutes, participe activement au réchauffement planétaire et envoie des messages d'erreur bizarres (car la configuration de madame michu n'est pas une configuration de développement par définition, c'est une distribution orientée poste de travail...) que seul un initié peut comprendre... Alors bonjour la duplication des efforts, et bonjour le boulot pour le pauvre zigue qui accepte de se taper le support technique et des remarques telles que "c'est quoi cette histoire de libmachin ??? Moi je veux juste XXX ! je comprends rien, c'est tout un foutoir pour installer un tout petit logiciel, c'est nul ton linux, [...]".
Je maintiens que la compilation n'est pas une opération à faire réaliser à tous les utilisateurs, seulement à ceux que ça intéresse (et éventuellement ceux qui n'auraient pas le choix, mais c'est un autre problème : il est extrêmement dommage de ne pas avoir le choix, quand il s'agit de logiciel libre...).--
#define MAGIC 0xdefaced /* I should've patented this number -cliph */-
[^]Re: Beurk
Posté par Raphaël SurcouF (Jabber id, page perso, ) le 07/01/2007 à 02:39. (lien). Évalué à 2.Les libertés des utilisateurs s'arrêtent là où commencent celles des développeurs, sachant que ce sont ces derniers, via les licences libres, qui accordent des droits et libertés sur les logiciels libres qu'ils développent.
-
[^]Re: Beurk
Posté par Gniarf () le 07/01/2007 à 17:40. (lien). Évalué à 1.là c'était pour le cas où madame Michu tenait à garder un bidule pas très répandu ou resté à une vieille version, contrairement à toi et au reste du monde. installé par son fiston et qui a le malheur de marcher juste assez bien pour elle. sauf que son Iceturd est troué, par exemple.
là tu parles d'un .deb, fort bien, et si elle n'a pas Debian ou clone ? tu vas lui dire d'installer le même système de toi puisqu'elle vient te demander ton expertise et sinon tu lui diras que tu ne peux pas l'aider plus que ça, même si oui tu l'aimes bien
que ça pête à la compilation parce que libmoisi.a n'est pas là ou que ça pête à l'installation ou l'utilisation parce que libmoisi.o n'est pas là, c'est pareil. c'est juste plus ou moins rapide - et pénible - pour s'en rendre compte.
par contre je note un énorme problème de compréhension chez toi ou plutot une bonne prise de vessies pour des lanternes, parce qu'on parle de logiciel libre ou d'une plateforme libre il serait extrement dommage qu'un utilisateur lamba ne puisse pas en profiter sans le moindre effort de sa personne, de quelque nature que ce soit (financière, discernement dans le choix du matériel ou de son Linux, acquisition d'un minimum de connaissances même de base comme "tu cliques là pour éteindre l'ordinateur, pas sur le bouton on/off"). oui, ça serait dommage. mais bon.
j'ai l'impression qu'une fois que quelqu'un code 3 lignes dans son coin et que ça marche chez lui, ça devient magiquement un droit divin pour lui que le reste du monde puisse automatiquement en profiter sans que lui fasse le mondre effort supplémentaire - après tout, il est un codeur, il ne va pas perdre son temps avec des détails bassement matériels comme savoir si ses utilisateurs peuvent utiliser son logiciel - et que ça marche partout tout seul sans jamais aucun problème.
100 balles et un Mars aussi ?--
Windows has no users. It has hostages.
-
-
-
-
-
[^]Re: Beurk
Posté par Gniarf () le 04/01/2007 à 15:07. (lien). Évalué à 0.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...
les utilisateurs de Gentoo sont des spécialistes, CQFD...
ou pas. donc il y a un problème dans ton raisonnement.--
Windows has no users. It has hostages.-
[^]Re: Beurk
Posté par Bruno Coudoin (page perso, ) le 04/01/2007 à 23:08. (lien). Évalué à 2.Même pour Gentool il y a un travail à faire avant de pouvoir compiler. c'est pas la même méthode que pour rpm et dpkg mais ça change rien au problème. Comment fait un utilisateur si personne n'a fait ce travail.
Ensuite demander à tout le monde de recompiler tout n'est pas une option car c'est trop long.--
http://gcompris.net logiciel educatif libre pour les enfants
-
-
-
-
[^]Re: Beurk
Posté par Larry Cow () le 04/01/2007 à 10:52. (lien). Évalué à 10.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 lasher () le 04/01/2007 à 12:24. (lien). Évalué à 3.Je vais faire mon vieux con ©. Un profane qui ne programme pas sur sa machine ne devrait pas avoir à y installer un compilateur, ne serait-ce que d'un point de vue sécurité : compiler un rootkit quand le compilateur est déjà accessible est quand même bien plus facile que s'il faut d'abord faire tout un tas de contorsions pour récupérer les droits root.
Pour le coup du « bleeding edge », je n'y crois pas du tout : par définition, sauf à avoir vraiment blindé le programme pour pouvoir s'installer partout (et à ce moment-là, s'agit-il encore de « bleeding edge » ?), il y a *toujours* un risque de plantage lors de la compilation. Et ton utilisateur, il se retrouve toujours très bête.-
[^]Re: Beurk
Posté par Morreale Jean Roc () le 04/01/2007 à 13:40. (lien). Évalué à 3.GCC disponible sur la machine d'un profane ça permet de compiler dynamiquement des modules kernels sans lui broyer les noix (ex: dkms)
-
[^]Re: Beurk
Posté par Misc (page perso, ) le 04/01/2007 à 13:52. (lien). Évalué à 2.gcc ne fournit pas des tarballs binaires de gcc à des fins de bootstrapping ?
-
[^]Re: Beurk
-
-
[^]Re: Beurk
Posté par Larry Cow () le 04/01/2007 à 13:53. (lien). Évalué à 4.Pour la sécurité, autant je trouve ça important sur un serveur, ou de manière général un système en production (disposant d'un administrateur capable de réfléchir un tant soit peu sa politique de mise-à-jour), autant c'est limite de l'enculage de mouche sur une machine personnelle. Typiquement, sur un système dont le propriétaire est potentiellement capable d'éxécuter n'importe quel script en root (parce qu'on le lui a demandé et qu'il a le moyen de le faire, mais pas de savoir si c'est raisonnable ou non), s'interdire d'avoir un compilateur me paraît un peu vain. Si la chose est inutile, c'est toujours mieux de s'en passer, mais de là à refuser les solutions source-based sous prétexte que le compilateur représente un risque...
Quant au plantage à la compilation, sur des vraies releases (je parle pas non plus de faire ça sur du CVS/SVN), ça me paraît relativement fiable. Il suffit de voir le nombre de paquets Gentoo qui compilent très bien partout. Après tout, c'est le mainteneur du logiciel qui serait chargé de définir les caractéristiques de son bébé, et c'est probablement le plus apte à le faire. Au pire, il peut toujours indiquer dans son paquet un niveau de "fiabilité" de la chose, qui pourrait même être évalué automatiquement par un système de remontée automatique et anonyme des erreurs de compilation.-
[^]Re: Beurk
Posté par Raphaël SurcouF (Jabber id, page perso, ) le 04/01/2007 à 14:14. (lien). Évalué à 2.Par plantage, il faut souvent comprendre « problème de dépendances de compilation » que l'utilisateur débutant a du mal à cerner aux vues des nombreuses questions sur le sujet qui pollue les listes et autres forums.
-
[^]Re: Beurk
Posté par Laurent Pointal (page perso, ) le 04/01/2007 à 15:02. (lien). Évalué à 3.Ca peut même être assez vicieux, du genre la librairie X est bien là, et dans la bonne version, mais manque de chance elle a été compilée avec une option incompatible avec le soft Y que l'utilisateur veut installer...
-
-
[^]Re: Beurk
Posté par Gniarf () le 04/01/2007 à 15:12. (lien). Évalué à 1.Typiquement, sur un système dont le propriétaire est potentiellement capable d'éxécuter n'importe quel script en root (parce qu'on le lui a demandé et qu'il a le moyen de le faire, mais pas de savoir si c'est raisonnable ou non), s'interdire d'avoir un compilateur me paraît un peu vain
d'autant que les rootkit ne s'embetent pas et téléchargent un compilateur pour continuer leurs conneries...--
Windows has no users. It has hostages.-
[^]Re: Beurk
-
-
[^]Re: Beurk
Posté par nimnim () le 05/01/2007 à 09:36. (lien). Évalué à 2.> Pour la sécurité, autant je trouve ça important sur un serveur, ou de manière
> général un système en production (disposant d'un administrateur capable de
> réfléchir un tant soit peu sa politique de mise-à-jour), autant c'est limite de
> l'enculage de mouche sur une machine personnelle.
Je vois que le monsieur n'a jamais reçu de SPAM émis par les machines personnelles des défenseurs des mouches.-
[^]Re: Beurk
Posté par Larry Cow () le 05/01/2007 à 10:32. (lien). Évalué à 4.Je ne dis pas que la sécurité est inutile sur une machine personnelle, je dis juste que se priver de l'usage d'un compilateur sur un tel système alors que des tonnes d'autres failles potentielles (à commencer par l'utilisateur) existent, c'est du FF (fly-fucking, oeuf corse).
Si le pirate veut compiler du code sur ta plateforme, il n'a qu'à balancer un binaire de TCC, et c'est parti. Tu n'arrêteras pas grand monde en ne mettant pas GCC. Encore une fois, mettre un compilo là ou il ne sert à rien, c'est ballot. Mais se priver des services qu'il peut apporter pour des questions de sécurité, ça l'est autant.
-
-
-
-
-
-
-
-
[^]Re: Beurk
Posté par TImaniac (page perso, ) le 04/01/2007 à 09:49. (lien). Évalué à 6.Certes, mais doit-on réellement emmerder toute la communauté des utilisateurs de logiciels libres simplement pour faciliter l'introduction de logiciels propriétaires dans les distributions majoritaires ?
Certes, c'est demandé par les distributeurs de logiciels propriétaires, mais ca serait aussi un grand confort pour tous les utilisateurs de logiciels libres : l'utlisateur lambda de mandrake, ubuntu ou fedora il a une distribution à base de binaire, et qu'ils soient proprio ou pas, le problème est le même.
Et puis bon franchement, voir autant de distributions qui font toutes le même boulot de packaging en parrallèle, je trouve ca une perte de temps considérable.-
[^]Re: Beurk
Posté par Colin Leroy (page perso, ) le 04/01/2007 à 09:55. (lien). Évalué à 8.voir autant de distributions qui font toutes le même boulot de packaging en parrallèle, je trouve ca une perte de temps considérable.
Mais est-ce que ce n'est pas ça qui fait la différence entre un logiciel "posé là" avec une entrée de menu sans icône dans "Autres" et un logiciel bien intégré à la distro ?-
[^]Re: Beurk
Posté par Bruno Coudoin (page perso, ) le 04/01/2007 à 10:06. (lien). Évalué à 5.Il existe déjà un mécanisme standardisé par le freedesktop pour qu'une application précise ou son menu doit être placé. Les différentes catégorie sont déjà définie. Je ne vois pas trop la valeur du packaging de la distro la-dessus.
C'est même parfois génant, je ne suis pas capable de dire à mes utilisateurs clairement et présisément comment lancer GCompris car ça dépend de la distro !--
http://gcompris.net logiciel educatif libre pour les enfants-
[^]Re: Beurk
Posté par Marc Poiroud (Jabber id, page perso, ) le 04/01/2007 à 10:18. (lien). Évalué à 4.C'est même parfois génant, je ne suis pas capable de dire à mes utilisateurs clairement et présisément comment lancer GCompris car ça dépend de la distro !
Si le logiciel fourni un fichier .desktop alors l'entrée sera toujours dans le même menu, quelque soit la distro et quelque soit l'environnement.
D'ailleurs, il faut absolument penser à valider les fichier .desktop car c'est souvent la faute à l'auteur si l'entrée est mal faite.
http://www.freedesktop.org/wiki/Software/desktop-file-utils--
La chanson est une industrie parce qu’une poignée d’imbéciles a réussi à être moins con que le reste.
(Coluche)
-
[^]Re: Beurk
Posté par Pascal Terjan (Jabber id, page perso, ) le 04/01/2007 à 11:22. (lien). Évalué à 6.Oui, mais c'est recent, au cours des 10 années précédentes chaque distib avait fait son système et je ne pense pas que toutes aient fait la migration vers le support des .desktop...
De plus, tous les Window Manager ne supportent pas encore les menus freedesktop.
-
-
-
Difficile
Le problème est qu'on parle toujours des dépendances sans réellement réaliser qu'elles sont complètement différentes d'un système à un autre. Certains gestionnaire de paquetages peuvent "suggérer" l'installation d'autres paquetages. Des logiciels ont été divisés en plusieurs parties dans certaines distro (libifiés, par exemple), dans d'autres non. Je ne vois vraiment pas comment on peut résoudre tous ces problèmes sinon en contraignant toutes les distros à se ressembler complètement.
-
[+] [^]Re: Difficile
Posté par iug () le 04/01/2007 à 13:20. (lien). Évalué à -1.C'est bien là tout le problème.
Dans les systèmes de paquets actuels, chaque paquet informe des capacités qu'il fournit, et de celles dont il a besoin.
Il suffirait d'avoir un système de description des capacités standard, entre deb et rpm.
Le problème c'est qu'il y a surement trop de boulets intaigristes pour y parvenir.-
[^]Re: Difficile
Posté par Aurélien Girard () le 04/01/2007 à 13:32. (lien). Évalué à 7.C'est un peu plus compliqué que ça.
Les distributions proposent par exemple des granularités différentes : pour une même application (par exemple PHP) certaines vont par exemple fournir un gros paquet fourre-tout alors que d'autres vont proposer un paquet de base et un ensemble de paquets complémentaires (paquet de headers, pour tel ou tel module, etc.).
Le choix de granularité est un choix fort de chaque distribution. Le leur retirer serait pénalisant.
De manière plus générale, la valeur ajoutée apportée par chaque distribution est l'un des gros points forts du monde du logiciel libre. Tout standardiser en gommant leurs spécificités poserait le problème de la création d'une distribution de Linux/*BSD/autres unique qui proposeraient toutes la même chose.
C'est un peu le même problème que le monde UNIX a pu affronter sauf que la compatibilité au niveau sources a déjà rendu la situation beaucoup plus saine.
En tout cas, je souhaite bien du courrage au groupe de travail LSB qui s'attèle à un problème bien compliqué.-
[^]Re: Difficile
Posté par iug () le 04/01/2007 à 16:56. (lien). Évalué à 2.Il suffit de faire un système de description standardisé, que tel ou tel paquet fournisse telle ou telle capacité importe peu.
Le problème c'est que pousser le découpage trop loin rendrait caduc les systèmes de capacités définis.
Comme je disais, ce genre de choses nécessiterait un minimum de compromis entre les différents acteurs, et quand on voit les trolleurs que compte la communauté on est pas rendu, et c'est bien dommage. Il suffit de lire la suite des commentaires.
Rendre inter-opérable deb et rpm est simple du point de vue technique, le choix de l'inter-opérabilité est un choix purement politique qui doit être fait par les développeurs principaux de Debian, Gentoo, Redhat, Mandriva, Ubuntu et Suse. Il suffirait que Debian et Redhat se mettent d'accord pour que les autres suivent.
En tant qu'entreprise, Redhat y a tout intérêt. Debian a l'air de sortir de son extrémisme depuis peu (a mauvais escient je trouve, mais c'est le cas). On peut espérer que ça arrive un jour.
J'ai du mal à comprendre que d'un côté la communauté gueule pour l'inter-opérabilité des formats de fichiers, et que d'un autre côté elle ne fait pas de même avec ses paquets.
-
-
[^]Re: Difficile
Posté par letsyl () le 04/01/2007 à 13:39. (lien). Évalué à 1.Ne serait-il pas possible d'avoir un paquet dans une sorte de format intermédiaire contenant les sources et une descriptions des bibliothèques requises, qui pourrait être transformé en rpm ou deb ou... adaptés à chaque distrib ? Cet outil de "transformation" serait à développer par la distrib.
-
[^]Re: Difficile
Posté par Raphaël SurcouF (Jabber id, page perso, ) le 04/01/2007 à 14:15. (lien). Évalué à 4.Alien ?
-
[^]Re: Difficile
-
-
-
[^]Re: Difficile
Posté par Raphaël SurcouF (Jabber id, page perso, ) le 04/01/2007 à 14:23. (lien). Évalué à 4.À noter que le système Debian se trouve actuellement confronté (ou le sera très bientôt) à un problème de pertinences avec les outils de recherche se basant uniquement sur les noms et descriptions de paquets.
À tel point qu'un développeur Debian, Enrico Zini, a décidé de mettre en application les travaux d'un mathématicien et bibliothécaire indien, Shiyali Ramamrita Ranganathan[1], avec DebTags[2]. Si le format RPM pouvait adopter ce système de tags (tout comme celui de Debconf d'ailleurs), il y a gagnerait en fonctionnalité et les deux systèmes y gagnerait en harmonie.
Il n'y a pas qu'APT qui soit un bon système chez Debian.
Il faut savoir aussi que la différence majeure entre les deux formats est que les RPM basent leurs dépendances sur les fichiers là où les DEB s'appuient uniquement sur le système de dépendances.
[1]: http://fr.wikipedia.org/wiki/Shiyali_Ramamrita_Ranganathan
[2]: http://debtags.alioth.debian.org/-
[^]Re: Difficile
Posté par Pascal Terjan (Jabber id, page perso, ) le 04/01/2007 à 14:38. (lien). Évalué à 3.Il faut savoir aussi que la différence majeure entre les deux formats est que les RPM basent leurs dépendances sur les fichiers là où les DEB s'appuient uniquement sur le système de dépendances.
Heu tu exageres un peu. RPM _supporte_ les dépendances sur des fichiers mais c'est très rarement utilisé et c'est fortement déconseillé.
Je sais que sur Mandriva ca arrive dans un cas : quand ton cas contient des scripts, à la construction du package ca regarde les shebang et ca ajoute les interpretaurs comme dépendance. Quand l'interpréteur est présent sur la machine de build ca met une dépendance vers son package, sinon ca met vers le fichier. Donc on se retrouve avec une dépendance vers le fichier si on a oublié de mettre l'interpréteur comme dépendance de build et pas mis la dépendance à la main en ajoutant un ignore sur celle là.
Le seul cas ou je ne sais pas comment éviter c'est dans les scripts de pre/post/... ou rpm met tout seul un require sur le fichier de l'interpreteur. La plupart des packages ont donc une dépendance vers /bin/sh, et en plus elle apparait plusieurs fois par packet (pour dire qu'on a besoin de lui en pre, en post, ...).
Sur les 1789 installés sur ma machine :
[pterjan@plop tmp]$ rpm -qa --requires | grep / | sort | uniq -c | sort -nr
969 /bin/sh
878 /sbin/ldconfig
41 /sbin/install-info
26 /usr/sbin/update-alternatives
8 /usr/bin/perl
4 /sbin/chkconfig
3 /usr/sbin/groupadd
3 /bin/awk
3 /bin/ash
2 /usr/sbin/update-ldetect-lst
2 /usr/bin/tr
2 /usr/bin/python
2 /etc/pam.d/system-auth
2 /etc/init.d
2 /bin/sed
1 /usr/share/autotools/ac-wrapper.pl
1 /usr/sbin/useradd
1 /usr/sbin/glibc-post-wrapper
1 /usr/sbin/chkfontpath
1 /usr/sbin/arping
1 /usr/bin/run-parts
1 /usr/bin/ruby
1 /usr/bin/rrdcgi
1 /usr/bin/env
1 /usr/bin/cmp
1 /usr/bin/chage
1 /sbin/service
1 /sbin/pidof
1 /sbin/ip
1 /sbin/fuser
1 /etc/libuser.conf
1 /bin/touch
1 /bin/rm
1 /bin/grep
1 /bin/gawk
1 /bin/egrep
1 /bin/csh
1 /bin/bash
Quelques un sont des bugs mais la plupart ne sont que du bruit vu que c'est fourni dans le basesystem.-
[^]Re: Difficile
Posté par Raphaël SurcouF (Jabber id, page perso, ) le 04/01/2007 à 15:15. (lien). Évalué à 2.J'exagère à peine : il n'y a qu'à regarder les require de la majeure partie des paquets RPM. Il suffit souvent de disposer du fichier adéquat pour que le RPM accepte de s'installer. Ce n'est pas simplement rare, c'est largement utilisé.
Et quand on donne le choix aux utilisateurs, c'est comme des électrons, ils choisiront le chemin le plus court (comprendre : les dépendances sur les fichiers, ça va plus vite, un ldd et hop).-
[^]Re: Difficile
Posté par Pascal Terjan (Jabber id, page perso, ) le 04/01/2007 à 15:25. (lien). Évalué à 3.Ben justement j'ai regardé tous les packages de ma machine. Et il ne suffit pas que le fichier existe pour que le rpm accepte de s'installer, il faut qu'il soit fourni par un rpm installé !
La dépendance ne se fait pas sur la présence de fichiers sur le système, c'est juste que en quelque sorte les rpm provident tous les fichiers qu'ils contiennent. rpm n'utilise que sa db pour résoudre les dépendances, pas la présence physique de fichiers...
[root@plop SPECS]# rpm -ivh /home/pterjan/rpm/RPMS/i586/test-1-1mdv2007.1.i586.rpm
erreur: Dépendances requises:
/tmp/foo est nécessaire pour test-1-1mdv2007.1.i586
[root@plop SPECS]# touch /tmp/foo
[root@plop SPECS]# rpm -ivh /home/pterjan/rpm/RPMS/i586/test-1-1mdv2007.1.i586.rpm
erreur: Dépendances requises:
/tmp/foo est nécessaire pour test-1-1mdv2007.1.i586
-
[^]Re: Difficile
Posté par Raphaël SurcouF (Jabber id, page perso, ) le 04/01/2007 à 15:34. (lien). Évalué à 2.Hummm, au temps pour moi, c'est à la génération du paquet RPM qu'il exploite le ldd et les shells utilisés. Dans tous les cas, il faut construire les paquets dans une sandbox ou un chroot sous peine de voir surgir des problèmes de dépendances.
-
[^]Re: Difficile
Posté par Pascal Terjan (Jabber id, page perso, ) le 04/01/2007 à 15:44. (lien). Évalué à 2.Dans tous les cas, il faut construire les paquets dans une sandbox ou un chroot sous peine de voir surgir des problèmes de dépendances.
Oui c'est pourquoi il existe des systèmes de build. SUSE en a un, Mandriva aussi, je suppose que Fedora aussi mais je ne sais pas.
Tu donnes un src.rpm ou un spec + des fichiers sources et ca te rebuild et check le package avant de l'uploader.
Celui de Mandriva actuellement, tu commites tout dans le svn et quand ton package te parait OK tu demandes à ce qu'il soit uploadé, ca sort les trucs du svn, genere un chroot, installe les dependances de build et génère le package. Si tout c'est bien passé en i586 et x86_64 et que rpmlint n'indique pas d'erreur bloquante, c'est uploadé.-
[^]Re: Difficile
Posté par Raphaël SurcouF (Jabber id, page perso, ) le 04/01/2007 à 15:54. (lien). Évalué à 4.Et ce que fait également Debian avec son réseau de buildd pour ses 11 architectures.
-
-
-
-
[^]Re: Difficile
Posté par Pascal Terjan (Jabber id, page perso, ) le 04/01/2007 à 15:40. (lien). Évalué à 2.comprendre : les dépendances sur les fichiers, ça va plus vite, un ldd et hop).
Et j'avais oublié de répondre à cette partie.
Ca serait con de faire un ldd à la main pour ajouter des dépendances vers des fichiers quand mieux est déjà fait automatiquement.
C'est fait lors du build du rpm par des scripts d'ajout de dep automatique, et ils mettent pas le nom de fichier de la lib mais son soname. Quand on package des libs ça ajoute aussi automatiquement la fourniture du soname des libs inclues dans le package (les dépendances vers les modules perl sont aussi automatiques ainsi que quelques autres choses...)
Donc pourquoi les gens s'embeteraient ils à faire à la main des dépendances vers des fichiers plutot que d'avoir de dépendances automatiques propres ?
-
-
-
-
-
[^]Re: Difficile
Posté par Laurent Pointal (page perso, ) le 04/01/2007 à 15:07. (lien). Évalué à 2.Pour ce qui est de la problématique des dépendances, un logiciel devrait venir avec tout ce qui lui est nécessaire et qui n'est pas défini par la LSB. Il serait possible d'avoir quelques cas très limités où des applications pourraient dépendre d'autres composants.
Donc les dépendances sont relatives à ce qui est défini dans la LSB, pour le reste, faut packager avec l'application.
Ca risque de faire de gros packages, des duplications de librairies sur la machine, une utilisation plus importante de la mémoire... mais ça retire le "dll hell" - d'ailleurs il me semble que c'est sur cette voie que se sont lancés MacOS et Windows.-
[^]Re: Difficile
Posté par Michel Galle () le 04/01/2007 à 16:00. (lien). Évalué à 6.Hormis le fait qu'os X est contrôlé par une seule entité (apple) :
mac os X met à disposition un "framework" de développement très complet
(le fameux "cocoa" et sa myriade de kit/core associés et Carbon)
du coup, c'est très rare qu'un développeur sur os X ait subitement besoin d'une bibliothèque exotique
quand c'est le cas, il est en effet d'usage de l'intégrer DANS le "bundle" de l'application
(une application os X est un dossier qui peut contenir en plus du binaire des éventuelles bibliothèques, icones, etc)
il arrive donc que des programmes os X intègrent la même bibliothèque populaire parce qu'Apple ne propose rien encore d'équivalent. Un cas classique c'est quand les développeurs veulent imiter un aspect des logiciels d'Apple qu'Apple n'a pas encore standardisé dans os X.
dans les faits c'est rare (cocoa/carbon est tout de même très complet) et d'expérience, je n'ai pas ressenti que les programmes Mac prenaient une taille démentielle en comparaison de ceux de Linux.
Cela dit, si vous en êtes encore à compter les octets, oui os X n'est pas optimisé pour économiser le disque dur, mais conçu pour simplifier la vie des utilisateurs et des développeurs sans pour autant tomber dans un délire à la windows.
il faut bien réaliser qu'apple ,à chaque version d'os X, a agrandit "cocoa" , pour que tous les besoins des créateurs de programmes soient couverts. du coup, les développeurs n'ont pas eu besoin de partir dans le "dll hell" de windows.
un peu comme si Gnome (ou kde) absorbaient et fournissaient des fonctions de messagerie instantanée, de courrier, de vidéo, de base de donnée, de sécurité, d'animations, de sons, de jeux, de réseaux, etc etc
(j'ai utilisé le terme "cocoa" dans son sens le plus large, les puristes sépareront peut être Webkit, webcore , core-data, core-image, core-bidule etc de "cocoa" , mais dans la pratique , le tout forme une plateforme couvrant presque tous les usages ce qui limite le besoin d'une gestion de paquetages provenant de multiples sources)
bref, vla pourquoi os X n'a pas dégénéré en dll hell malgré son manque d'un véritable système de paquetage et dépendance.-
[^]Re: Difficile
Posté par Gof (Jabber id, page perso, ) le 04/01/2007 à 17:13. (lien). Évalué à 4.un peu comme si Gnome (ou kde) absorbaient et fournissaient des fonctions de messagerie instantanée, de courrier, de vidéo, de base de donnée, de sécurité, d'animations, de sons, de jeux, de réseaux, etc etc
Bha KDE fait ça.
Qt et les kdelibs fournissent un "framework" de développement très complets.
Les programme kde n'ont en général pas besoin d'autres dépendances.
-
-
.
Il existe http://autopackage.org qui marche déjà pas trop mal. Avec interface graphique et tout. En plus ça permet de clairement séparer les logiciels de la distro et les logiciels tiers.
-
[^]Re: .
Posté par Bruno Coudoin (page perso, ) le 04/01/2007 à 10:21. (lien). Évalué à 3."En plus ça permet de clairement séparer les logiciels de la distro et les logiciels tiers."
Hum, c'est pas si évident malheureusement. Les distros ne supporte pas bien le fait d'installer des logiciels ailleurs que dans /usr donc autopackage est obligé de se mettre dans /usr au milieu des logiciels de ta distro.
Le problème vient principalement des menus et des type mime. Il y a des répertoires centralisés pour eux donc obligation de les respecter.
Mais oui clairement autopackage n'est pas la panacée mais c'est mieux pour un projet de livrer ça que juste un tarball. Au moins un utilisateur lambda à une chance de pouvoir utiliser ton logiciel.--
http://gcompris.net logiciel educatif libre pour les enfants-
[^]Re: .
Posté par Gof (Jabber id, page perso, ) le 04/01/2007 à 10:39. (lien). Évalué à 2.> Les distros ne supporte pas bien le fait d'installer des logiciels ailleurs que dans /usr
Ah bon ? Pourquoi ?
Normalement il est prévu qu'on puisse installer des logiciel ailleurs. C'est à ça que servent les variables d'environnements $PATH, $LD_LIBRARY_PATH, $XDG_DATA_DIRS (cette dernière est justement utilisée pour les menus et les types mimes)-
[^]Re: .
Posté par Bruno Coudoin (page perso, ) le 04/01/2007 à 10:51. (lien). Évalué à 4.La réponse en anglais sur le site de autopackage http://autopackage.org/faq.html#2_3
En gros, ça marche pour certaines distro, pas pour d'autres. Ils ont dont choisi de se fixer sur /usr ca c'est ce qui marche le mieux.--
http://gcompris.net logiciel educatif libre pour les enfants-
[^]Re: .
Posté par Raphaël SurcouF (Jabber id, page perso, ) le 04/01/2007 à 11:18. (lien). Évalué à 7.Oui mais c'est ce qui présente également le plus de risque de conflits avec le système installé et la gestion de paquets.
Je préfère encore que les utilisateurs compilent leurs logiciels à la ./configure; make; make install, au moins, ça ira tout droit dans /usr/local
Si AutoPackage utilise /usr par défaut parce qu'ils n'ont pas de solutions pour ajouter les chemins de /usr/local dans la configuration système, excuse-moi, mais c'est de la pure fainéantise : il suffirait d'ajouter /usr/local/lib dans /etc/ld.so.conf et de modifier le $PATH dans un /etc/profile. Et s'ils ne sont pas capables de deviner le shell utilisé par le système...
Utiliser /usr parce que /usr/local n'est pas intégré dans les chemins par défaut sur la majorité des distributions est une mauvaise excuse.
-
-
[^]Re: .
Posté par Jeanuel (Jabber id, page perso, ) le 04/01/2007 à 12:27. (lien). Évalué à 3.> Les distros ne supporte pas bien le fait d'installer des logiciels ailleurs que dans /usr
et /opt, c'est pour ranger les pizza /opt ?
Bon, ok, toutes les distris n'ont pas de /opt mais c'est facile à arranger mkdir /opt. pouf-pouf.-
[^]Re: .
Posté par Aurélien Girard () le 04/01/2007 à 12:37. (lien). Évalué à 1.Et /usr/local ? On m'a toujours dit que les bidules supplémentaires devaient s'installer dans /usr/local. On m'aurait menti ?
-
[^]Re: .
Posté par Benoît Sibaud (Jabber id, page perso, ) le 04/01/2007 à 13:20. (lien). Évalué à 4.Filesystem Hierarchy Standard 2.3 :
http://www.pathname.com/fhs/
« /opt is reserved for the installation of add-on application software packages. »
« The /usr/local hierarchy is for use by the system administrator when installing software locally. It needs to be safe from being overwritten when the system software is updated. It may be used for programs and data that are shareable amongst a group of hosts, but not found in /usr »-
[^]Re: .
Posté par Aurélien Girard () le 04/01/2007 à 13:36. (lien). Évalué à 5.Dans le contexte Desktop (le seul impacté par le problème des binaires passe-partout, j'en ai l'impression), l'administrateur est l'utilisateur de la machine (ou en tout cas l'utilisateur principal) et toute installation est locale.
Je ne voit donc pas en quoi, dans un contexte Desktop toujours, /opt devrait être préféré à /usr/local selon la définition FHS. Et plus généralement, si on sort de la nomenclature FHS (qui n'est pas si standard que ça apparament) je vois encore moins la différence.
J'ai oublié un détail ?
PS: si quelqu'un a le background UNIX nécessaire pour m'expliquer à quoi correspond des "programs and data that are shareable amongst a group of hosts" je suis preneur-
[^]Re: .
Posté par baud123 (Jabber id, page perso, ) le 04/01/2007 à 14:09. (lien). Évalué à 5.PS: si quelqu'un a le background UNIX nécessaire pour m'expliquer à quoi correspond des "programs and data that are shareable amongst a group of hosts" je suis preneur
Tu peux tout à fait imaginer qu'un parc homogène de stations de travail bootent par le réseau, ce qui permet d'avoir des "terminaux" évolués (et indifférenciés) ainsi qu'une gestion centralisée des mises à jour / ajouts de programmes pour tout le parc.
Le /usr/local permet de différencier les applications pour ton site : cela correspond à des applications qui sont adaptées à ton besoin (ou ceux de tes utilisateurs) mais qui n'ont pas vocation à être gérées de manière standard au niveau de la configuration. Par exemple, quand en admin' en central intervient en région, cela l
-
-
-
-
-
-


Cette discussion est archivée, il n'est plus possible de laisser des commentaires.
Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.