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 #889318.
Run by 
Cette page a été générée par Templeet en 0.0631s (dont 0.0063 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
checkinstall
je suis assez d'accord avec toi sur le principe. Le système archlinux me semble vraiment intéressant, je n'ai pas encore testé mais cela me tente bien.
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
Tous ensemble contre l'esclavitude des logiciels privateurs !
[^]Re: checkinstall
Dire, par exemple on bloque sur la libc 2.7, sur xorg 7.3 etc
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
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 :)
Tous ensemble contre l'esclavitude des logiciels privateurs !
[^]Re: checkinstall
> Pourquoi on a /usr/games/nethack ?
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
ouais \o/ la LSB, avec ses 53 versions et variantes soit déjà presque autant que de versions d'une distribution classique, et puis ses 3-4 modules (Core, C++, Desktop...) histoire d'égaler les versions Discovery, Destkop, Corporate, Server... ah, et j'oubliais, on ajoute encore une dimension parce qu'on s'ennuyait : par architecture matérielle.
oui, c'est sûr, un tit logo "Linux Standard Base" ca fera bien sur l'emballage...
Windows has no users. It has hostages.
[^]Re: checkinstall
ouais, bah ça :-)
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
Je ne connais pas checkinstall, mais à priori, je n'aime pas trop cette solution. Surtout car je n'ai aucune maîtrise de ce qui se passe.
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.
La Roue du Temps
[^]Re: checkinstall
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
Il faut comprendre ce que je dis ... Si je dis un make install dans /usr/local, ca veut dire que je télécharge les sources dans /usr/src, je fait un tar xvf et make install sans rien d'autre.
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é.
La Roue du Temps
[^]Re: checkinstall
Ah oki, je vois ce que tu veux dire, désolé.