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
Journal Problèmes d'installation des logiciels : paquets sources ?
10
déc.
2007
# Compatibilité
Posté par Nerdiland de Fesseps . Évalué à 7.
Une distro voulant se vanter d'une certaine stabilité risque de ne pas être enchantée à cette idée, d'autres ont déjà un système du genre, cherchant plutôt l'équilibre entre la bidouille et le paquet officiel : les dépôts du type contrib ou universe. Au final on arrive toujours à la même chose.
Que ce soient les pkgbuilds, les slackbuilds ou tout autre système du même genre, on ne contribue qu'à une seule distribution. Il suffit d'en changer pour se retaper le script/paquet des programmes qui ne sont pas dans le dépôt officiel.
La solution que j'aime bien, et que tu cites, c'est Zero Install. Il est relativement simple de faire une interface (pour un binaire et/ou une source à compiler), c'est indépendant de la distro, c'est simple à utiliser, c'est sécurisé, on peut regarder dans les logiciels installés par la distro pour éviter de télécharger des dépendances inutiles, on peut installer plusieurs versions d'un même programme, etc etc
Personnellement je trouve ça idéal pour distribuer les logiciels tiers dont tu parles. Ça gagne vraiment à être utilisé et bidouillé, et je cherche encore les inconvénients sur le fond. On peut même spécifier plusieurs SE dans une interface (une version Linux x86, Linux x86-64 et FreeBSD x86 dans la même interface par exemple).
# Re:
Posté par IsNotGood . Évalué à 3.
Oui, on peut faire des fichiers spec qui vont récupérer les sources sur le web ou dans svn, etc...
Oui, il y a des dépôts qui existent avec ça.
Mais, ce n'est pas dans la philosophie de Fedora. Donc c'est peut-être moins bien que ArchLinux (que je ne connais pas).
De plus, il y a souvent des problèmes légaux (pas seulement des problèmes de brevets).
Bref, techniquement il n'y a pas de problème. Mais comme je n'utilise pas, je ne peux pas en dire plus.
Donc dit précisément ce que tu veux (par exemple "je veux installer bidule"), et si quelqu'un connait l'existance d'un paque rpm ou d'un dépôt il te l'indiquera.
En passant, pose ta question sur http://www.fedora-fr.org/ . Tu auras plus de chance d'avoir une réponse satisfaisante.
Lis la FedoraFaq non officielle : http://www.fedorafaq.org/
Il y a de nombreux dépôts Fedora :
http://rpm.livna.org/
http://freshrpms.net/
http://dag.wieers.com/
http://atrpms.net/
http://newrpms.sunsite.dk/
http://dribble.org.uk/
NB : livna, freshrpms et dribble font fusionner :
http://rpm.rpmfusion.org/
ATTENTION : Les dépôts sont parfois d'une qualité variable et souvent compatibles entre eux.
Donc si tu mélanges des dépôts et que ça sucks, ne soit étonné. Tu auras été prévenu.
[^] # Re: Re:
Posté par Olivier Serve (site web personnel) . Évalué à 5.
Autrement dit, Fedora sucks by design. Merci de l'avoir dit aussi clairement.
[^] # Re: Re:
Posté par Jean-Philippe Garcia Ballester (site web personnel) . Évalué à 2.
[^] # Re: Re:
Posté par liberforce (site web personnel) . Évalué à 3.
[^] # Attention au malentendu
Posté par Axel . Évalué à 6.
Au cas où tu ne l'aurais pas deviné, Fedora n'est pas une distribution Linux ! Et non, Fedora n'est qu'une vitrine technologique pour Redhat, et ne vise pas du tout à fournir des logiciels ni à Mme Michu, ni au premier hacker venu qui voudrait développer ou créer des paquets de ses logiciels favoris.
Les plus affutés d'entre vous auront compris que tout ceci ce n'est qu'une version hypocrite et de mauvaise foi des bons vieux DIY & RTFM.
J'imagine ton immense déception, mais c'est hélas la stricte propagande que certains aiment à utiliser pour contrer les critiques vérité.
[^] # Re: Attention au malentendu
Posté par GeneralZod . Évalué à 1.
Même si ça manque de ";-)", "Pierre Tramo j2ee Architecte", je suppose que le reste est une forme d'humour.
[^] # Re: Attention au malentendu
Posté par Axel . Évalué à 4.
:D
[^] # Re: Attention au malentendu
Posté par IsNotGood . Évalué à 1.
Si faire avancer le logiciel libre c'est être une vitrine technologique, alors oui.
[^] # Re: Re:
Posté par IsNotGood . Évalué à -1.
Idem pour toi.
J'ai vu des tonnes de "avec machin il n'y a pas de problème, on peut tout faire". Bref, j'ai vu des tonnes de mensonges.
[^] # Re: Re:
Posté par GeneralZod . Évalué à 3.
Hein, des dépôts tiers incompatibles entre eux, c'est un peu le lot de la plupart des distributions ... Par contre, ça commence à se décanter du côté de Fedora.
[^] # Re: Re:
Posté par Olivier Serve (site web personnel) . Évalué à 0.
Non, mais Fedora et les autres distribs ne proposent rien pour éviter ça.
[^] # Re: Dépôts tiers
Posté par zebob . Évalué à 2.
La seule chose que les distros pourraient faire, c'est d'encourager la création d'écoles/de guide d'empaquatages afin de former des mainteneurs motivés pour le cas des logiciels non-empaquetés.
[^] # Re: Dépôts tiers
Posté par GeneralZod . Évalué à 4.
Il y a quelques empaqueteurs francophones de Fedora (et des bons, pas des charlots) mais également EPEL, Livna qui trainent sur ce chan et qui seront ravis de vous aider, faire des revues de paquets et vous sponsoriser.
[^] # Re: Re:
Posté par Mildred (site web personnel) . Évalué à 1.
Et qi je veux deux programmes qui sont dans deux déps différents incompatibles, alors je peux essayer (et je le ferais probablement, par faute d'autre alternative) et ça risque de mal marcher.
Dernière solution, faire ses propres paquets ... mais comme ce n'est pas immediat (surtout avec rpm) même si ce n'est pas difficile, j'aimerais bien partager mon travail avec d'autres. C'est un peu ça mon idée. Mais comme je n'ai ni l'envie, ni l'énergie de maintenir un dépôt à moi, je ne le ferais probablement pas :( domage.
Ou alors, trouver un moyen de partager les fichiers spec ...
Et le problème c'est que j'ai très souvent des programmes que je veux utiliser non packagés, juste quelques exemples:
- gspaceui
- wmctrl
- gtkradiant
- python-urwid
- bzr-svn
- aiccu
- aptoncd
...
[^] # Re: Re:
Posté par BAud (site web personnel) . Évalué à 2.
euh non, hormis pour les gros dépôts "officiels"
mieux vaut rebuilder un rpm si tu en as vraiment besoin pour ta version de distrib'. À partir du src.rpm c'est encore moins compliqué que de repartir de zéro.
Bon après si tu veux pourrir ta base de gestion de version avec 15000 dépôts plus hétéroclites et incompatibles entre eux les uns que les autres, cela te regarde...
Pour les paquets que tu ne trouves pas, dès lors qu'ils sont libres tu peux les suggérer en terme de paquets à réaliser, comme cela ils seront intégrés upstream et tout le monde en bénéficiera (à quoi bon bosser dans son coin ?). S'ils ne sont pas libres, mieux vaut investir sur des équivalents libres... cela sera plus pérenne.
[^] # Re: Re:
Posté par Mildred (site web personnel) . Évalué à 1.
Il y a aussi des programmes qui n'ont peut être pas beaucoup de chance d'être intégrés ... tellement ils sont lourds. Delta3D [http://www.delta3d.org/] par exemple ... enfin je n'ai pas demandé
[^] # Re: Re:
Posté par IsNotGood . Évalué à 4.
Ben tu le fais.
Si t'exiges aux autres de le faire, alors on peut t'exiger de le faire.
[^] # Re: Re:
Posté par Gniarf . Évalué à 2.
maintenant, rester dans un rôle de consommateur passif à attendre en râlant que ça soit intégré sans vouloir s'impliquer ou contribuer... parait que c'est pas toujours efficace.
[^] # Re: Re:
Posté par IsNotGood . Évalué à 1.
En gros c'est l'idée pour un utilisateur "normal". Pour un utilisateur "pointu", il peut faire son/ses paquet(s). J'ai deux ou trois paquets "perso".
> Et qi je veux deux programmes qui sont dans deux déps différents incompatibles, alors je peux essayer (et je le ferais probablement, par faute d'autre alternative) et ça risque de mal marcher.
Pas forcément. Individuellement les paquets sont rarement incompatibles.
Ce que tu peux faire, c'est réaliser ton propre dépôt avec des paquets copiés de divers dépôts. Createrepo (du paquet createrepo) te permet de faire un dépôt les doigts dans le nez. C'est juste une commande à lancer puis il faut ajouter le dépôt nouvellement créé à la configuration de yum. Et voilà.
> - wmctrl
C'est dans Fedora (trouvé en faisant "yum search").
> - aiccu
C'est dans Fedora.
> Ou alors, trouver un moyen de partager les fichiers spec ...
C'est ce que fait Fedora (mais n'autorise que ce qui est libre) :
http://fedoraproject.org/wiki/PackageMaintainers/Join
Tu trouveras dans le cvs plein d'exemples de fichiers spec :
http://cvs.fedoraproject.org/viewcvs/
[^] # Re: Re:
Posté par Mildred (site web personnel) . Évalué à 1.
[^] # Re: Re:
Posté par IsNotGood . Évalué à 1.
http://lepouf.free.fr/downloads/Radiant/
[^] # Re: Re:
Posté par GeneralZod . Évalué à 2.
Je note que aptoncd peut être avantageusement remplacé par yum dans Fedora.
[^] # Re: Re:
Posté par Mildred (site web personnel) . Évalué à 0.
Je doute que yum puisse télécharger des paquets ubuntu, si ?
[^] # Re: Re:
Posté par GeneralZod . Évalué à 1.
[^] # Re: Re:
Posté par IsNotGood . Évalué à 0.
L'avantage de Yum c'est que tu peux le faire pour Fedora :-)
Passons.
Tu devrais peut-être regarder pour utiliser la virtualisation de Fedora. Par défaut F8 utilise KVM (c'est activé dans le noyau par défaut) et il te faudra un cpu supportant VT. Sinon il faut installer kernel-xen et que Ubuntu supporte Xen.
NB: Xen est actuellement plus évoluer mais Fedora va l'abandonner petit à petit au profit de KVM/Qemu.
Cette page devrait t'aider :
http://fedoraproject.org/wiki/Docs/Fedora8VirtQuickStart
# Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: universe et PPA
Posté par zebob . Évalué à 10.
[^] # Re: universe et PPA
Posté par Gniarf . Évalué à 2.
http://www.happyassassin.net/2007/10/24/mistakes/
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
# checkinstall
Posté par B16F4RV4RD1N . Évalué à 3.
Pour une installation rapide à partir des sources, s'intégrant pas trop mal à la distribution (permet de retirer facilement le programme par la suite), il y a checkinstall que tu connais peut-être. Le soucis c'est qu'il ne gère pas les dépendances, et que sur certains programmes le paquet ne se fait pas toujours (parfois c'est facile à corriger, parfois pas).
L'avantage c'est que c'est aussi rapide à faire que de taper un "make install" (make checkinstall à la place, bon 5 lettres de plus seulement).
Mais cette multiplicité des paquets, cette redondance de travail "pour rien", sont un problème.
J'avais soumis quelques questions à l'époque :
http://linuxfr.org/~farvardin/22989.html
On m'avait dit que chaque distribution avait des versions trop différentes pour pouvoir s'entendre.
Et bien justement, ne serait-il pas possible de s'entendre pour des bases stables, redéfinies à intervalle régulier, sur lesquels ces paquets pourraient être bâtis ? Dire, par exemple on bloque sur la libc 2.7, sur xorg 7.3 etc
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: checkinstall
Posté par BAud (site web personnel) . Évalué à 3.
ce que propose Linux_Standard_Base (LSB) par exemple ?
à qui cela sert-il hormis aux softs proprios ?
faire un paquet ne prend pas réellement de temps pour celui qui y est habitué, le tester en revanche...
[^] # Re: checkinstall
Posté par B16F4RV4RD1N . Évalué à 1.
oui, sauf que l'on se retrouve avec des distributions qui ont bcp de paquets disponibles (genre Debian), et d'autres où c'est la misère (genre opensuse, mais là aussi il semble que c'est en train de changer et de s'améliorer). C'est quand même du temps de perdu que d'avoir tous ces efforts pour seulement une distribution alors que toutes pourraient en bénéficier.
justement, un seul format de paquet permettrait d'avoir plus de testeurs, ceux de chaque distribution.
cela pourrait servir à tout le monde, en mettant toutes les distributions sur un pied d'égalité au niveau des logiciels disponibles.
De plus, il faudrait standardiser les noms des dépendances. Pourquoi c'est machin-dev sous debian, machin-devel sous suse ?
Standardiser également les emplacements des fichiers. Pourquoi on a /usr/games/nethack ? C'est pas assez sérieux pour mettre dans /usr/bin ? Pourquoi pas faire un /usr/toys/xeyes tant que l'on y est (il est dans /usr/bin d'ailleurs), ou un /usr/network/firefox un /usr/graphics/gimp etc ? Cela pourrait apporter encore plus de confusion et différence d'interprétation, qui semblent si chers aux développeurs linux :)
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: checkinstall
Posté par zul (site web personnel) . Évalué à 2.
Parce qu'a l'origine, tout le monde n'avait pas le droit de jouer :D
Voir man hier(8) sur une BSD et le group games :).
Rien à voir avec les dev linux donc. Ca existe depuis l'origine d'Unix.
[^] # Re: checkinstall
Posté par Gniarf . Évalué à 2.
oui, c'est sûr, un tit logo "Linux Standard Base" ca fera bien sur l'emballage...
[^] # Re: checkinstall
Posté par BAud (site web personnel) . Évalué à 2.
ils ont au moins le mérite de proposer une réponse à ceux qui prônent le yakafokon et - clairement - cela montre que ce n'est pas simple (hormis tout figer dans le temps ou tout avoir en libre, ce qui évite en partie la majeure partie des soucis).
[^] # Re: checkinstall
Posté par Mildred (site web personnel) . Évalué à 1.
Si je fais un make DESTDIR= install, je sais exactement où vont aller les fichiers installés ... le checkinstall reste flou. Sans compter nombre de projets (sont tout mes projets) qui n'utilisent pas de Makefiles mais d'autres systèmes comme un simple script bash, jam, (s)cons, cmake, ...
Pour moi c'est autant un hack que le make install dans /usr/local ... un peu plus maintenable, c'est vrai, mais pas la bonne solution.
[^] # Re: checkinstall
Posté par morphalus . Évalué à 2.
Tiens, FreeBSD et son système de ports qui installe tous les logiciels tiers dans /usr/local est en fait un hack géant ? ...
[^] # Re: checkinstall
Posté par Mildred (site web personnel) . Évalué à 2.
J'ose espérer que FreeBSD, lorsqu'il installe un port (et peu importe où il l'installe) enregistre quels fichiers il a installé, et que ces fichiers appartiennent bien au port installé.
[^] # Re: checkinstall
Posté par morphalus . Évalué à 1.
# Historique
Posté par FabienC . Évalué à -1.
Si on unifiait déjà ça, ça permettrait aux éditeurs de logiciel de n'avoir qu'un "installeur" linux a créer, moins de compétence a avoir, plus de temps, il n'y aura un seul .deb et tout le monde pourrait l'utiliser.
[^] # Re: Historique
Posté par ʭ ☯ . Évalué à 6.
Il faut savoir que vu la spécificité des compilations sous chaque distribution (choix d'optimisation, etc.) les paquets qu'elles font ne marchent pas souvent sur une autre distribution.
Il est par contre très simple de faire un paquet qui fonctionne partout (cf. logiciels propriétaires : Flash, RealPlayer n'ont qu'un seul binaire qui marche partout). Par contre ces binaires sont forcément plsu gros (ils intègrent les librairies (compilation statique) pour être sûr de ne pas manquer de quelque chose.
Mais alors, pourquoi depuis 6 ans ce n'est pas plus courant? Parce qu'il est moins fatiguant de faire {urpmi yum apt-get install} firefox que d'aller chercher sur le site de Mozilla le binaire. Les gros projets le font quand même (OOo). Je me souviens que Gcompris était fourni en RPM jusqu'à ce que son développeur se fatigue de le préparer.
Bref, ce qu'il manque, c'est des mimines qui ont envie de faire des RPM universels - RPM est exigé par la LSB depuis longtemps.
A nous les libristes de nous y mettre.
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: Historique
Posté par B16F4RV4RD1N . Évalué à 6.
ps : un véritable habitué de Debian reste à Debian sur le "desktop", pas besoin d'Ubuntu ;)
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: Historique
Posté par BAud (site web personnel) . Évalué à 1.
ah sur ppc et x86_64 aussi ? on m'aurait menti ? :D
[^] # Re: Historique
Posté par dguihal . Évalué à 3.
[^] # Re: Historique
Posté par Mildred (site web personnel) . Évalué à 1.
Donc non.
Avec RPM, tu as un fichier spec, qui te donne l'URL du paquet (encore faut il développer un soft pour le télécharger, actuellement, c'est fait à la main), qui te dis comment le décompresser, le compiler, et l'installer adns un faux dossier racile qu'on peut ensuite packager. (un peu comme les PKGBUILD d'Arch en plus puissant (sur certains aspects) et plus compliqué)
[^] # Re: Historique
Posté par Misc (site web personnel) . Évalué à 10.
Parmi les problémes, il y a les versions de logiciels, les noms des libs, la politique d'intégration ( menu, systéme de démarrage, etc ).
Au nom de la compatibilité avec les autres pour le monde commercial, on devrait interdire à Canonical de pousser Upstart ? À Fedora de mettre un perl plus récent ( genre 5.10 ) non compatible binairement avec le 5.8 ? À Mandriva de compiler kde avec l'option -fvisiblity ?
Le monde du libre vit grace à son bordel et la liberté qui l'engendre. Il y a rien qui incite vraiment à garder la compatiblité, rien dans le sens ou une distro qui ferait ça n'aurais pas d'avantage si visible que ça face aux autres. Ça passerais si le monde du libre n'était pas si fertile mais c'est pas vraiment le cas.
[^] # Re: Historique
Posté par Mildred (site web personnel) . Évalué à 2.
Si chacun s'y met, et crée des fichiers spec pour les paquets qu'il aime, et partage son travail avec les autres, d'un coup il y a moins de travail à fournir globalement et individuellement (on profite de ce que les autres ont partagé).
# pkgsrc
Posté par 태 (site web personnel) . Évalué à 3.
Le problème, ils préfèreront installer leur propre perl, leur propre python, leurs propres dépendances plutôt que celui de ta distribution vu qu'il est coton d'installer des bibliothèques perl sans toucher aux dossiers où il est installé.
L'autre problème, il n'y a pas plus de paquets que dans debian, mais on peut mettre simplement en place des repositories (dans macports en tout cas) et donc on peut avoir des branches de paquets non testés.
[^] # Re: pkgsrc
Posté par zul (site web personnel) . Évalué à 3.
Ca reste une approche classique (un dépôt géré par la communauté). Il est juste peut-etre plus simple (et mieux documenté, au moins par l'exemple) de faire des packages pour une 'distribution' source.
[^] # Re: pkgsrc
Posté par Mildred (site web personnel) . Évalué à 2.
[^] # Re: pkgsrc
Posté par 태 (site web personnel) . Évalué à 2.
[^] # Re: pkgsrc
Posté par Mildred (site web personnel) . Évalué à 1.
Mais il me semble que quand j'avais regardé ce n'étais pas encore vraiment le cas.
Pour la compilation, bien sûr il faut des machines pour la faire au niveau de la distrib, mais il y a plein de petites distribs qui arrivent à s'en sortir ... et je ne pense pas que Gentoo soit une petite distrib. Et pas besoin de supporter les binaires sur s'importe quelle architecture si les ressources sont limitées.
[^] # Re: pkgsrc
Posté par 태 (site web personnel) . Évalué à 2.
http://www.netbsd.org/docs/pkgsrc/using.html#using-pkg pour savoir comment utiliser les paquets binaires dans pkgsrc.
[^] # Re: pkgsrc
Posté par zul (site web personnel) . Évalué à 2.
(Sinon c'est aussi utilisé pour voir les regressions et les paquets qui compilent pas : voir http://mail-index.netbsd.org/pkgsrc-bulk/ pour l'ensemble des bulk générés et les rapports qui vont bien).
# Today it sucks, tomorrow it won't
Posté par Eric Heintzmann . Évalué à 4.
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
Posté par farib . Évalué à 3.
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
Posté par Nicolas Schoonbroodt . Évalué à 10.
Même fédora et archlinux me semblent plus facile...
[^] # Re: Today it sucks, tomorrow it won't
Posté par B16F4RV4RD1N . Évalué à 4.
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.
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: Today it sucks, tomorrow it won't
Posté par farib . Évalué à 0.
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
Posté par B16F4RV4RD1N . Évalué à 5.
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.
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: Today it sucks, tomorrow it won't
Posté par farib . Évalué à 1.
[^] # Re: Today it sucks, tomorrow it won't
Posté par B16F4RV4RD1N . Évalué à 1.
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
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: Today it sucks, tomorrow it won't
Posté par farib . Évalué à 2.
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
Posté par B16F4RV4RD1N . Évalué à 1.
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...
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: Today it sucks, tomorrow it won't
Posté par Raphaël SurcouF (site web personnel) . Évalué à 3.
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
Posté par Gniarf . Évalué à 2.
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
[^] # Re: Today it sucks, tomorrow it won't
Posté par Mildred (site web personnel) . Évalué à 2.
[^] # Re: Today it sucks, tomorrow it won't
Posté par B16F4RV4RD1N . Évalué à 2.
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: Today it sucks, tomorrow it won't
Posté par Thomas Douillard . Évalué à 3.
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
Posté par farib . Évalué à -2.
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
Posté par Gniarf . Évalué à 2.
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.
[^] # Re: Today it sucks, tomorrow it won't
Posté par IsNotGood . Évalué à 1.
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
Posté par letsyl . Évalué à 3.
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
Posté par Gniarf . Évalué à 2.
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.
[^] # Re: Today it sucks, tomorrow it won't
Posté par Mildred (site web personnel) . Évalué à 1.
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.
[^] # Re: Today it sucks, tomorrow it won't
Posté par Gniarf . Évalué à 2.
ce qui restera aura en général un vrai problème de license par rapport à la distribution concernée (comme Squeak)
# Stow c'est bon, mangez-en
Posté par Olivier Guerrier . Évalué à 1.
En français approximatif, ça donne:
GNU Stow aide l'administrateur système à organiser les fichiers dans /usr/local/ en permettant à chaque logiciel d'être installé dans sa propre arborescence dans /usr/local/stow/, et en utilisant des liens symboliques pour créer l'illusion que tous ces logiciels sont installés à la même place.
D'accord c'est pas un outil à mettre dans toutes les mains, mais c'est sympa pour installer des trucs pas standards...
# Assez...
Posté par Raphaël SurcouF (site web personnel) . Évalué à 6.
Pourquoi serait-ce donc la faute à la conception même des systèmes de paquets, aux cycles de publications des distributions ? Pour qu'un logiciel soit intégré à une distribution, il « suffit » de demander à ce qu'il le soit (RFP chez Debian) ou de proposer de le faire soi-même (ITP pour Debian).
Dès qu'on demande à ces messieurs (ceux-là même qui critiquent) de contribuer aux dites distributions avant de venir se plaindre, il n'y a plus personne. Ne leur viendraient-ils pas à l'esprit que, si certains logiciels ne sont pas disponibles dans telle ou telle autre distribution, c'était tout simplement parce que PERSONNE n'a daigné préparé un paquet binaire pour celle-ci, ou alors, sans jamais contribuer à cette dernière, en le gardant pour soi.
Or, si ces messieurs sont capables de compiler tant bien que mal (surtout quand on a connu ArchLinux...) ces logiciels dont ils ont tant besoin, pourquoi ne pas faire l'effort de proposer le résultat à tous, tout simplement, en respectant le format utilisé ?
Donc, non, Mildred (tu ne serais pas un second « ciol » ?), il n'est pas possible d'envisager de proposer AUR comme LA solution « idéale » pour installer des logiciels sous Linux, ne serait-ce parce que certaines distributions n'acceptent pas pour des raisons diverses et variées (sans doute futiles pour toi, comme la sécurité, la fiabilité, la stabilité, etc.). Imagine un instant qu'un esprit malicieux oserait publier un script dont le code consisterait simplement à effacer toute donnée dans les systèmes cibles ? Un script assez bien écrit toutefois pour que cela passe inaperçu (oui, cela serait également possible avec un dépôt non officiel pour Fedora, Debian, Ubuntu, ou autre sauf qu'il s'agirait précisément de dépôts non officiels). Il y a besoin d'un certain nombre de garde-fou pour que seules les personnes les plus motivées et compétentes puissent contribuer effectivement aux distributions actuelles. Entre proposer et maintenir un paquet, travail au combien ingrat s'il en est, il y a tout un monde.
Puisque vous semblez de plus en plus nombreux, mettez donc vos idées de développement en commun et proposez-nous quelque chose de construit la prochaine fois (une nouvelle distribution révolutionnaire en somme). En attendant, ce genre de débat stérile ne fait pas beaucoup avancer les choses.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.