Journal : Problèmes d'installation des logiciels : paquets sources ?
Posté par Mildred (Jabber id, page perso, ) le 09 décembre 2007
Bonsoir,
Une problématique que je trouve importante pour nos bureaux libres concerne à mon avis l'installation des logiciels tiers. Pourquoi donc me dites-vous ? C'est vrqi, nous avons quand même les packages qui sont vraiment pratiques. Cependant ...
je ne remet pas en cause les packages, au contraire. Ils sont vraiment une pièce maîtresse du système. Cependant, ils ne nous permettent que d'installer des logiciels spécifiquement pour la distribution qu'on a installé. Et les logiciels non packagés ... tant pis pour nous.
la solution qui nous reste, c'est quoi ? 0install, klik, autopackage, compilation à la main dans /usr/local ? Certaines de ces solutions ont l'air intéressantes ... mais il y a la aussi le problème de la limite du nombre de logiciels packagés. Et pour la compilation à la main dans /usr/local, elle présente deux inconvénients majeurs:
- ce n'est pas intégré au système de paquets
- il faut un certain niveau pour être capable de compiler soi même des tarball sources. Surtout si des problèmes surviennent pendant la compilation.
Une autre solution qu'on trouve dans la distribution ArchLinux, c'est AUR, c'est un repository de scripts qui peuvent automatiquement télécharger la source depuis Internet et créer un paquet ArchLinux. Un grand avantage c'est que c'est partagé, donc il est du coup possible à n'importe qui de packager le soft qu'il veut et le proposer aux autres.
Un tel script (appelé PKGBUILD) est très simple, c'est en fait un script shell qui a la structure suivante:
pkgname=...
pkgver=...
...
makedepends=(make gcc ...)
depends=(glibc ...)
source=(http://.../${pkgname}-${pkgver}.tar.gz)
build(){
cd "$startdir/src/$pkgname-$pkgver"
./congifure --prefix=/usr && make && make DESTDIR="$startdir/pkg" install
}
Comme vous le voyez, n'importe qui qui est capable de compiler un logiciel dans /usr/local peut faire un PKGBUILD et pour le coup intégrer son logiciel correctement à la distribution.
Quelque chose d'encore mieux, il existe un logiciel appelé yaourt qui permet en une seule ligne de compiler un logiciel à partir des PKGBUILD sur AUR en même temps que ses dépendances, un peu comme portage sur gentoo. Vraiment génial.
Seulement, si tout était aussi bien, ... En fait j'ai décidé il y a peu d'abandonner ArchLinux au profit de Fedora 8. Pourquoi ? Tout simplement parce qu'ArchLinux est une distribution pour utilisateurs expérimentés ... Et je fesait un peu trop d'administration système à mon goût. Je voulais quelque chose d'un peu mieux, et lorsqu'on regarde des projets de Fedora comme ceux-ci, ca donne envie:
- http://fedoraproject.org/wiki/Features/OneSecondX
- http://fedoraproject.org/wiki/Features/RandrSupport
- http://fedoraproject.org/wiki/Releases/FeatureBetterStartup
- http://fedoraproject.org/wiki/Features/FedoraElectronicLab
- http://fedoraproject.org/wiki/Features/EFI
Donc me voila sous Fedora ... C'est très bien, j'ai un boot graphique avec X11, l'administration est facilitée par les nombreuses petites applications qui évitent de toucher aux fichiers de configuration. Il y a aussi l'exclusion par défaut des paquets de développement qui permettent de réduire la place occupée par l'OS de manière non négligable. Mais, je me rend compte que Fedora contient beaucoup moins de packages que n'avais ArchLinux.
Peu importe me dis-je, je vais faire des paquets RPM ... Et je cherche sur le web comment faire des spec file et comment les transformer en paquets RPM. Ce n'est pas forcément plus compliqué mais il y a certaines différences:
- il est très facile de faire des fichiers spec qui s'installent sur le système. Il faut faire attention à bien définir BuildRoot.
- les sources ne se téléchargent pas toute seules
- comment faire des spec file qui téléchargent de repositories svn ??? je ne sais pas
- pas d'outil comme yaourt qui permet d'installer facilement plein de spec files à la fois
- pas de repository de spec file où on pourrait partager.
Pour toutes ces raisons, je trouve la vie difficile avec Fedora, même si cette distribution a de nombreux avantages, j'envisage de revenir à ArchLinux ... Mais j'aimerais bien rester avec Fedora.
Tout le but de mon long discours, c'était pour proposer une nouvelle manière de voir le problème de l'installation des logiciels sous GNU/Linux. A mon avis, toutes les distributions gagneraient à intégrer un système comme AUR ou n'importe quel utilisateur peut proposer un script pour compiler automatiquement un paquet qui ne serait pas fourni de base. Un peu comme gentoo, mais avec les paquets binaires en plus.
Vous avez des remarques à faire ...? Des suggestions sur les endroits où je pourrais poster mes idées ?
Mildred
Une problématique que je trouve importante pour nos bureaux libres concerne à mon avis l'installation des logiciels tiers. Pourquoi donc me dites-vous ? C'est vrqi, nous avons quand même les packages qui sont vraiment pratiques. Cependant ...
je ne remet pas en cause les packages, au contraire. Ils sont vraiment une pièce maîtresse du système. Cependant, ils ne nous permettent que d'installer des logiciels spécifiquement pour la distribution qu'on a installé. Et les logiciels non packagés ... tant pis pour nous.
la solution qui nous reste, c'est quoi ? 0install, klik, autopackage, compilation à la main dans /usr/local ? Certaines de ces solutions ont l'air intéressantes ... mais il y a la aussi le problème de la limite du nombre de logiciels packagés. Et pour la compilation à la main dans /usr/local, elle présente deux inconvénients majeurs:
- ce n'est pas intégré au système de paquets
- il faut un certain niveau pour être capable de compiler soi même des tarball sources. Surtout si des problèmes surviennent pendant la compilation.
Une autre solution qu'on trouve dans la distribution ArchLinux, c'est AUR, c'est un repository de scripts qui peuvent automatiquement télécharger la source depuis Internet et créer un paquet ArchLinux. Un grand avantage c'est que c'est partagé, donc il est du coup possible à n'importe qui de packager le soft qu'il veut et le proposer aux autres.
Un tel script (appelé PKGBUILD) est très simple, c'est en fait un script shell qui a la structure suivante:
pkgname=...
pkgver=...
...
makedepends=(make gcc ...)
depends=(glibc ...)
source=(http://.../${pkgname}-${pkgver}.tar.gz)
build(){
cd "$startdir/src/$pkgname-$pkgver"
./congifure --prefix=/usr && make && make DESTDIR="$startdir/pkg" install
}
Comme vous le voyez, n'importe qui qui est capable de compiler un logiciel dans /usr/local peut faire un PKGBUILD et pour le coup intégrer son logiciel correctement à la distribution.
Quelque chose d'encore mieux, il existe un logiciel appelé yaourt qui permet en une seule ligne de compiler un logiciel à partir des PKGBUILD sur AUR en même temps que ses dépendances, un peu comme portage sur gentoo. Vraiment génial.
Seulement, si tout était aussi bien, ... En fait j'ai décidé il y a peu d'abandonner ArchLinux au profit de Fedora 8. Pourquoi ? Tout simplement parce qu'ArchLinux est une distribution pour utilisateurs expérimentés ... Et je fesait un peu trop d'administration système à mon goût. Je voulais quelque chose d'un peu mieux, et lorsqu'on regarde des projets de Fedora comme ceux-ci, ca donne envie:
- http://fedoraproject.org/wiki/Features/OneSecondX
- http://fedoraproject.org/wiki/Features/RandrSupport
- http://fedoraproject.org/wiki/Releases/FeatureBetterStartup
- http://fedoraproject.org/wiki/Features/FedoraElectronicLab
- http://fedoraproject.org/wiki/Features/EFI
Donc me voila sous Fedora ... C'est très bien, j'ai un boot graphique avec X11, l'administration est facilitée par les nombreuses petites applications qui évitent de toucher aux fichiers de configuration. Il y a aussi l'exclusion par défaut des paquets de développement qui permettent de réduire la place occupée par l'OS de manière non négligable. Mais, je me rend compte que Fedora contient beaucoup moins de packages que n'avais ArchLinux.
Peu importe me dis-je, je vais faire des paquets RPM ... Et je cherche sur le web comment faire des spec file et comment les transformer en paquets RPM. Ce n'est pas forcément plus compliqué mais il y a certaines différences:
- il est très facile de faire des fichiers spec qui s'installent sur le système. Il faut faire attention à bien définir BuildRoot.
- les sources ne se téléchargent pas toute seules
- comment faire des spec file qui téléchargent de repositories svn ??? je ne sais pas
- pas d'outil comme yaourt qui permet d'installer facilement plein de spec files à la fois
- pas de repository de spec file où on pourrait partager.
Pour toutes ces raisons, je trouve la vie difficile avec Fedora, même si cette distribution a de nombreux avantages, j'envisage de revenir à ArchLinux ... Mais j'aimerais bien rester avec Fedora.
Tout le but de mon long discours, c'était pour proposer une nouvelle manière de voir le problème de l'installation des logiciels sous GNU/Linux. A mon avis, toutes les distributions gagneraient à intégrer un système comme AUR ou n'importe quel utilisateur peut proposer un script pour compiler automatiquement un paquet qui ne serait pas fourni de base. Un peu comme gentoo, mais avec les paquets binaires en plus.
Vous avez des remarques à faire ...? Des suggestions sur les endroits où je pourrais poster mes idées ?
Mildred
> Lire le journal (79 commentaires, moyenne: 2,4).
Vous avez demandé le commentaire #889175.
Run by 
Cette page a été générée par Templeet en 0.1016s (dont 0.0193 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Today it sucks, tomorrow it won't
A ce propos, Ian Murdock a écrit 2 articles, en anglais:
http://ianmurdock.com/?p=388
http://ianmurdock.com/?p=391
Et la Linux Foundation a un wiki sur le sujet, en anglais aussi:
http://www.linux-foundation.org/en/Packaging/Wiki
[^]Re: Today it sucks, tomorrow it won't
Bon article.
Dommage qu'il faille s'appeller Ian Murdoch pour pouvoir reconnaitre des avantages de facilité à Windows par rapport à linux sans qu'on remette systématiquement en cause ta probité...
[^]Re: Today it sucks, tomorrow it won't
Extrait d'un mail que j'ai imprimé tout à l'heure pour mon cousin qui n'a pas internet. Il a un jeu acheté (pas une copie) qui ne marche plus sur son nouvel ordinateur (sous windows, le système facile)
Même fédora et archlinux me semblent plus facile...[ Répondre ] Ce commentaire est-il impertinent ou utile ?
[^]Re: Today it sucks, tomorrow it won't
très bon l'exemple :)
Ce genre de truc aussi c'est pas super convivial... (je n'indique pas cela juste parce que c'est un virus, mais parce que ce genre de manipulation me rebute plus que de patcher un noyau et le recompiler... et apparemment c'est le quotidien de bcp d'utilisateurs windows) :
http://www.infos-du-net.com/forum/62690-11-gros-virus
en ce qui concerne le texte de ian murdock sur l'installateur .exe qui facilite la vie sous windows (la première partie du moins, je n'ai pas lu le reste en détail), je trouve cela étonnant de la part de l'initiateur de Debian...
S'il y a qque chose que je trouve infiniment plus pratique sous linux, c'est bien la gestion des paquets. Cela doit être psychologique le côté "on va rechercher le logiciel avec un navigateur internet et on l'installe en cliquant dessus". À quand les fichiers .deb sur emule ou kazaa pour les rendre plus attractifs envers les "powerusers" windows ?
Je ne dis pas que le fait de pouvoir installer des paquets tiers autrement que par le gestionnaire de paquets est un mal, au contraire, et pas seulement pour des logiciels proprio, cela peut être de petits programmes non encore packagés officiellement. Mais cela ne devrait pas devenir un réflexe systématique ou la manière par défaut, plus un palliatif.
Tous ensemble contre l'esclavitude des logiciels privateurs !
[^]Re: Today it sucks, tomorrow it won't
je trouve cela étonnant de la part de l'initiateur de Debian....
Et re CQFD, le mec a pas tenu un propo "linux c'est génial, windows sapu" donc son propos n'est pas conforme à la ligne officielle qui consiste à refuser toute critique, donc c'est bizarre, forcément.
Le fond du propos de Ian Murchoch, c'est que même si le systeme Windows est développé de façon centralisé (c'est le cas de le dire puisqu'une seule et meme entité en est en charge) l'écosysteme de windows est développé de façon autonome et totalement décentralisé.
Et dans l'opensource, c'est l'inverse, alors que par essence, l'opensource c'était la décentralisation des développement, on observe que tout est en fait ultra-centralisé d'une part par le noyeau (intégration de ton module dans git ) et la distribution (intégration d'un logiciel dans les dépots). On est plus si libres que ça... cf le thread sur Apple qui dirige Webkit.
[^]Re: Today it sucks, tomorrow it won't
ouais, c'est tellement mieux comme conception... cet écosystème c'est quoi ? C'est les shareware à 2 balles codés en visual basic pour afficher les périphériques disponibles (que l'on a avec lspci sous le systère centralisé) ou lister les répertoires avec la taille des fichiers qu'il y a dedans (j'ai cherché longuement, mais pas pour chez moi bien sûr, un freeware décent qui fasse cela sous windows, alors qu'en ligne de commande ou avec kde c'était réglé). Ou alors les spyware ?
Ou encore ce pilote bluetooth, que m'a rapporté une connaissance, sur son beau windows vista tout frais, qui plantait la machine avec un bel écran bleu lors de chaque démarrage après son installation... bien entendu pas la faute à vista, la faute de l'écosystème qui contribue bénévolement à tous ces utilitaires indispensables...
Finalement, s'il doit y avoir une cathédrale et un bordel, Linux c'est la cathédrale, et windows le bordel. On me fera difficilement accepter que ce dernier représente une conception supérieure.
non pas forcément. Des critiques sur Linux et les LL, j'en lis tous les jours sur linuxfr, souvent à juste titre. Tiens il n'y a pas longtemps avec openoffice 2.3.0 lorsque l'on accédait à un fichier distant via samba sous linux, cela mettait ce fichier distant à 0, pas très sympa mais assez étonnant (vérifié sur 2 machines différentes), mais je n'ai même pas eu le temps d'en parler sur un forum OOo que c'était déjà corrigé avec la 2.3.1
Linux n'est certes pas parfait, mais ce n'est pas pour autant que reprendre ce qui fait tous les travers de windows (base de registres, une certaine conception anarchique de ergonomie cf vista) le rendra meilleurs.
Tous ensemble contre l'esclavitude des logiciels privateurs !
[^]Re: Today it sucks, tomorrow it won't
Tout va bien, ca prouve que tu n'as juste rien compris au propos de Ian Murdoch. Moinsse moi, ca te defoulera. Vive linuxfr.
[^]Re: Today it sucks, tomorrow it won't
ben non tu vois, je ne t'ai pas "moinssé" sur ce coup-là, et je n'ai pas besoin de me défouler, je suis calme :)
Ensuite, par rapport aux propos de murdoch, ben oui, des fois cela ne se passe pas aussi facilement lorsque c'est packagé n'importe comment, mais d'un autre côté c'est pas la mer à boire de savoir installer un logiciel en ligne de commande lorsque cela n'a pas été correctement packagé.
Si le logiciel de sun avait été packagé avec autopackage, cela aurait été facile à installer. Évidemment c'est vers ce genre de facilité auquel il faut tendre, mais je ne vois pas en quoi windows avec ses installateurs .exe de m**** serait un modèle à ce niveau (là je commence à perdre mon calme effectivement). À mon avis au niveau de la facilité d'utilisation, le système de paquets sous mac os x est bien plus probant. Rien à installer, le paquet peut se déplacer d'une machine à l'autre tel quel, se lancer depuis n'importe quel disque dur etc
Tous ensemble contre l'esclavitude des logiciels privateurs !
[^]Re: Today it sucks, tomorrow it won't
Si le logiciel de sun avait été packagé avec autopackage, cela aurait été facile à installer. Évidemment c'est vers ce genre de facilité auquel il faut tendre, mais je ne vois pas en quoi windows avec ses installateurs .exe de m**** serait un modèle à ce niveau (là je commence à perdre mon calme effectivement). À mon avis au niveau de la facilité d'utilisation, le système de paquets sous mac os x est bien plus probant. Rien à installer, le paquet peut se déplacer d'une machine à l'autre tel quel, se lancer depuis n'importe quel disque dur etc
Je crois que tu passes a cote du probleme. Le probleme n'est pas d'avoir un systeme d'installation genial (RPM,DEB, MSI y arrivent tous tant bien que mal) mais d'avoir un point d'entree unique. Et c'est bien gentil de vouloir expliquer que les ISV sont mechant pas beaux avec leurs softs proprios tout pourri qui ont 15 ans d'age qui veulent pas utiliser autopackage, mais c'est la vie. Je me repete ( et je reprend les propos de Murdoch), meme avec autopackage, quel interet de supporter le libre avec ses 50 systemes de paquets different qui va te couter 50 equipes de packaging en plus pour augmenter ton marche de 0.3%.
Maintenant, c'est bien rigolo de vouloir comparer l'installeur Mac avec son OSX unique et sa 10aine de modele d'ordinateurs supportes avec la diversite des distributions linux et des architectures, et surtout, n'oublie pas de comparer aussi la part de marche de linux avec la part de marche des macs. Car avant de bouffer Windows, hein, il aura fallu bouffer Mac, et meme ca, c'est pas gagne.
[^]Re: Today it sucks, tomorrow it won't
pour les parts de marché, on verra comment cela va évoluer, mais à mon avis cela représente plus que 0.3 % d'augmentation. Pour le bureau, c'est encore un peu différent, mais là aussi cela va évoluer rapidement (oui je sais cela fait 10 ans que l'on dit cela...)
Il n'y a pas tant de systèmes de paquets que cela, 3 principaux, et encore on peut facilement installer une version à partir d'un paquet différent (sous opensuse j'ai déjà pu installer des rpm issus de fedora ou des deb, sous debian j'ai pu installer des rpm mandriva etc ok c'est pas très propre mais cela fonctionne), comme quoi il n'y a pas tant de différence que cela entre les distributions. À mon avis en respectant un peu plus les LSB on devrait arriver à qque chose de bien. Quand à réaliser un paquet autopackage (ou zero install etc), je ne pense pas que cela fasse un trop gros trou dans le budget des oracle et compagnie. Avec bcp moins de moyen planeshift arrive à nous sortir de très bon autopackage qui fonctionnent sur toutes les distributions à ma connaissance.
.
Il y a quand même 2 architectures différentes, ppc et intel, et les développeurs arrivent bien à faire un paquet unique. OK, cela augmente la taille des paquets, mais cela fonctionne bien (si on fait abstraction tout de même de la frénésie d'Apple à "oublier" les anciennes version de son système dans la conception des nouvelles API). Le fait que les machines apple sont limitées en modèle est un faux pb, un logiciel qui tourne sur un "vrai" mac tournera sans doute pareil sur un pc normal bidouillé pour avoir mac os x.
Je pense que si on sort un paquet pour gcompris (je prends cet exemple car je sais que l'auteur est sensible à cette question des paquets), si cela sort pour PPC, i386 et x64, cela me semble bien suffisant, tant pis pour les "pauvres" admin de S/390 ou Sparc qui ne pourront pas faire jouer le petit dernier à gcompris sur le Mainframe de la société...
J'ai lu entièrement la seconde partie du texte de Murdock, mais il n'y a pas vraiment de proposition concrète ; "yakafokon fasse une API pour que les ISV puissent packager leurs applis.". L'idée est louable, mais cela reste encore bien vague...
Tous ensemble contre l'esclavitude des logiciels privateurs !
[^]Re: Today it sucks, tomorrow it won't
Oracle fournit un dépôt[1] non officiel pour Debian/Ubuntu pour Oracle Database XE.
Comme quoi, si les fournisseurs tiers daignaient enfin reconnaître les formats de paquets binaires des principales distributions. D'autant que ça ne demande pas énormément de ressources puisque certains bénévoles comme Dag Wiiers maintiennent des paquets RPM pour plusieurs distributions et plusieurs versions concurrentes de celles-ci sans trop de problèmes...
Il n'y aurait donc que deux formats principaux à fournir : pour passer d'une distribution à une autre, il faudrait juste adapter un minimum le paquet (avec des outils comme pbuilder[2] pour Debian/Ubuntu ou DAR[3] pour les RPM
[1]: http://www.oracle.com/technology/tech/linux/install/xe-on-ku(...)
[2]: http://doc.ubuntu-fr.org/pbuilder
[3]: http://dag.wieers.com/home-made/dar/
[^]Re: Today it sucks, tomorrow it won't
arrete un peu. les ISV ils ont déjà un point d'entrée unique, il s'appelle Red Hat, et les autres distributions peuvent aller se faire cuire un oeuf.
et vu leurs tarifs, le coup d'une Red Hat c'est cadeau en général. et pour les crevards, il y aura CentOS et autres clones, le tout avec un petit clin d'oeil, ça leur suffira largement
Windows has no users. It has hostages.
[^]Re: Today it sucks, tomorrow it won't
Euh ... Les paquets sous Mac OS X sont loins d'être les fichiers .dmg qu'on trouve sur le net avec un dossier .app dedans ... Un paquet Mas OS X te propose un petit assistant suivant-suivant-terminer comme sur Windows ou avec Autopackage et sert plutôt à installer des extensions au système (par exemple rEFIt, le support pour le système de fichier ext3, ...)
La Roue du Temps
[^]Re: Today it sucks, tomorrow it won't
oui, cela aussi ça existe. Si j'ai écrit "paquet", c'est pour éviter de dire "fichiers .dmg qu'on trouve sur le net avec un dossier .app dedans", le vrai nom je ne connais pas.
Tous ensemble contre l'esclavitude des logiciels privateurs !
[^]Re: Today it sucks, tomorrow it won't
Oui, mais non.
Pour un logiciel utile mais pas connu, utilisé par une communauté restreinte, mais utilisé, c'est pas forcément évident de le faire intégrer dans une distro, surtout si c'est récent, et que le logiciel en question ne concerne pas une population à tendance geekesque.
Bon, cela dit typiquement ce type de logiciel n'est pas forcément développé sous Linux ... bizarre ? Pas tant que ça peut être ...
Évidemment OOo est dans toutes les distros. C'est pas forcément le cas de logiciels moins gros ou moins connus.
[+] [^]Re: Today it sucks, tomorrow it won't
Voila, CQFD, qu'est-ce que je dis, paf, on carricature mes propos, et on prend bien l'exemple de la techno universellement reconnue comme pourrie pour les jeux (qui est très loin de représenter la majorité des jeux, heureusement).
Encore que la on est dans un cas ultra particulier avec les DRM/Anticopie de jeux vidéo ce qui est limite hors sujet avec lSV qu'évoquait Ian Murdoch, qui aux final doivent proposer 10 000 fois plus de progicels qu'il n'existe de jeux vidéos commerciaux.
[^]Re: Today it sucks, tomorrow it won't
oui enfin, je cite : "let me first point out that our goal is to create a vibrant third party software ecosystem around Linux - you know, like the one Microsoft has built around Windows."
ils veulent faciliter l'installation et l'utilisation de logiciels commerciaux, enfin, propriétaires. disons par exemple, les jeux, des bidules comme Real Player ou Adobe Flash Player et divers softs proprio biens chers et bien spécialisés qui existaient sous divers Unix avant.
soit. c'est gentil de courtiser ces gens-là (et on pourrait rappeller le nouveau poste de Ian Murdoch, mais chut) mais ce n'est pas l'objectif poursuivi par un grand nombre des "contributeurs du libre" qui par conséquent se foutent de cette initiative qui ne résoud pas LEURS problèmes de libristes parce que pour eux ca ne change que le packaging et pas le fait que ça ne marche pas sur leur plateforme ou que le soft serait quand même mieux avec quelques menus en plus et quelques bidules en moins
inutile de venir râler si ce Flash Player n'est disponible que sur Intel 32 bits ensuite, par exemple. et une réponse du style "mais le Flash Player n'est déjà disponible que sur Intel 32 bits !" montrerait que tu n'as pas saisi la nuance.
Windows has no users. It has hostages.
[^]Re: Today it sucks, tomorrow it won't
Juste, mais....
Le "libriste" n'est souvent pas que dans la "mouvance" libre.
Il y a des libristes qui sont prêt à payer pour avoir un système qui a des contraintes qu'on trouve principalement dans le proprio (stabilité API/ABI, long support). Il y a des libristes qui utilisent par exemple Fedora pour leur activité 100 % libriste et RHEL (ou clone) pour leur serveur web, en entreprise, etc.
Le libre n'est plus un truc qui est uniquement développé en fonction de l'humeur des développeurs. Il rend des services, il a donc une certaine responsabilité.
Voir par exemple EPEL :
http://fedoraproject.org/wiki/EPEL
Mais tu as raison, dans les développeurs du libre c'est minoritaire.
[^]Re: Today it sucks, tomorrow it won't
Je te trouve un peu réducteur, ce problème n'est pas spécifique aux logiciels propriétaires (même s'il s'en trouve accentué).
Quand un logiciel libre n'est pas disponible pour sa distro favorite, il faut alors le compiler soi même. Cei n'est pas forcément trivial, surtout pour des utilisateurs débutants.
Exemple concret, mumble un (excellent) logiciel "à la" Teamspeak n'est pas dispo pour ma distrib et demande une version de la bibiothèque qt4 très récente. Au contraire, il existe un .exe tout simple pour les utilisateurs windows.
Evidemment les systèmes de gestion de paquets sont infiniments plus pratiques qu'un .exe, mais dans certains cas, il serait intéressant d'avoir un système qui permette d'utiliser un logiciel quelle que soit la distrib (peut être klik ?).
[^]Re: Today it sucks, tomorrow it won't
et demande une version de la bibiothèque qt4 très récente
euh là le coupable est facile à trouver :) tu cries au choix après ta distribution qui a osé ne pas fournir une bibliothèque sortie 2 mois après elle, ou après les développeurs qui ont choisi une bibliothèque pas encore présente dans les distributions couramment utilisées
d'ailleurs ils fournissent ce logiciel et pas une dépendance qui semble nécessaire mais impossible à satisfaire par la plupart des utilisateurs ? c'est un peu ballot, à se demander s'ils veulent qu'on utilise leur soft.
le fait qu'il existe sous windows sous forme d'un setup.exe est anecdotique : quelqu'un a fait le sale boulot de packaging, c'est tout, idem que si c'était sous OS X.
Windows has no users. It has hostages.
[^]Re: Today it sucks, tomorrow it won't
Attention: third party software est différent de logiciel propriétaire !
Il y a plein de logiciels libres (bon, peut être pas tant que ça, mais un peu quand même) qui ne sont pas packagés, ou alors rarement. En particulier tout ce qui touche à la 3D j'ai remarqué, par exemple planeshift (sans l'artwork non libre), crystal space, ogre et les moteurs qui l'utilisent comme yake, delta3d et ses nombreuses dépendances.
Pouvoir les installer facilement serait une grande amélioration sur nos systèmes.
La Roue du Temps
[^]Re: Today it sucks, tomorrow it won't
oh vraiment ? c'est le seul cas pertinent. le reste se trouve dans les sections non-free ou autre plf ou universe des distributions. et si ton soft libre-ou-presque n'y est pas, mets-toi au boulot, tout simplement
ce qui restera aura en général un vrai problème de license par rapport à la distribution concernée (comme Squeak)
Windows has no users. It has hostages.