Bonsoir mon petit journal,
Aujourd'hui, profitant des petits moments perdus pendant mon stage (hum, n'allez pas croire que je ne fais rien :-)), j'ai laissé mon esprit vagabonder sur un sujet qui me turlupine depuis .. oh certainement depuis que je me suis mis à linux. J'ai commencé à écrire rapidement, à mes moments perdus, un petit document qui détaille la chose : http://cyberdivad.free.fr/projet-gest-comp.html(...)
Plus j'y pense et plus je me dis que ça doit être faisable, et je souhaite soumettre mon idée à votre esprit oh combien critique.
Je résume l'idée en quelques mots : un outil de gestion de compilation de logiciels.
En un peu plus long : je pense qu'il doit être possible de mettre un outil au point capable d'automatiser autant que possible la compilation de logiciels à partir de sources et surtout d'apporter à cette opération une interface plus attractive pour le néophyte. Tout le monde n'est pas prêt à s'investir pour assimiler des solides de notions de programmation rien que pour compiler un logiciel, et je le comprends parfaitement. En même temps, beaucoup de logiciels ne sont fournis que sous forme de sources ou ne proposent pas de packaging adaptée à la distribution de l'utilisateur.
En plus, intégrer un logiciel fraîchement compilé au système de packages d'une distrib n'est pas non plus à la portée du premier venu.
Moi je vois plusieurs manques très importants :
- dépendances demandées par le logiciel pas évidentes à gérer
- intégration à la distrib pas terrible (si on installe pleins de softs à partir des sources, c'est le souk).
- complexité non négligeable (compilation, création de paquet, gestion des erreurs, etc.)
- dans pleins de logiciels, les dépendances demandées par le ./configure ne sont pas conformes à celles indiquées dans le fichier INSTALL (exemple : fsv fournit avec INSTALL vide !)
- productivité faible. Ben oui, faut surveiller la compilation/configure et mêmes lancer les différentes étapes, ce qui implique de rester à côté. Toujours sympa de découvrir le matin qu'une (grosse, genre kde ou autre monstre) compilation lancée le soir avait en fait plantée dix minutes apres le départ !
- etc.
Bon, je vous laisse parcourir le document, qui explique ça plus en détail.
Journal Idée du jour
28
avr.
2004
# Déjà fait ?
Posté par Boa Treize (site web personnel) . Évalué à 1.
http://www.netbsd.org/Documentation/software/packages.html(...)
Utiliser pkgsrc sous Slackware :
http://users.piuha.net/martti/comp/slackware/slackware.html(...)
# Re: Idée du jour
Posté par lorill (site web personnel) . Évalué à 1.
[^] # Maven
Posté par Quzqo . Évalué à 1.
Au boulot, nous l'utilisons pour :
- créer une distribution
- gérer/générer nos sources
- diffuser la doc' projet ET distribution
- installer les plate-formes...
Comme quoi cet environnement est plein de ressources ;o)
A essayer même s'il faut être persévérant et que son utilisation nécessite pas mal de travail (plugins, adaptation des procédures...)
# Re: Idée du jour
Posté par 0xDEADBEEF . Évalué à 2.
[^] # Re: Idée du jour
Posté par Cyberdivad . Évalué à 1.
Je ne te suis pas, rpm permet d'apporter une interface utilisateur à la compilation de logiciels ?
Moi, je ne parle pas de packager des logiciels (bien qu'il y ait ce mot quelque part dans le document mais dans un autre but), mais de faciliter la compilation, de manière indépendante de la distrib. En gros, faire une sorte de front-end, comme il en existe pour quantité de logiciels en ligne de commande.
Mon idée n'a rien à voir avec la création d'un rpm-like. Cela dit elle n'est peut-être pas viable, c'est pour ça que je la soumet à la critique des lecteurs de linuxfr :-)
[^] # Re: Idée du jour
Posté par -=[ silmaril ]=- (site web personnel) . Évalué à 1.
Donc bon.
y a rpm --build
dpkg-buildpackage (et d'autres apparement y en a meme qui preparent le /debian/)
emerge (lui encore plus que d'autres meme si je n'aime pas l'idée faut reconnaitre qu'il marche bien).
...
[^] # Re: Idée du jour
Posté par Cyberdivad . Évalué à 1.
Perso, je suis parti du constat que même avec un configure, c'est une plaie pour compiler la plupart des logiciels : je le lance une fois, oh il me manque tel lib, je relance, encore une lib à installer, et ainsi de suite. Et je ne parle que des libs mentionnées nulle part dans le fichier INSTALL ou le README (quand il existent). Parfois, je suis obligé d'abandonner, ne voyant pas à quel lib peut bien faire référence le message d'erreur.
Je me dit qu'à partir des messages retournés par le configure (voire meme en analysant ce fichier, mais je ne m'y connais pas assez pour le dire), il doit être possible d'installer automatiquement les dépendances manquantes en passant par le système de gestion de packages de la distrib.
[^] # Re: Idée du jour
Posté par -=[ silmaril ]=- (site web personnel) . Évalué à 1.
ex simple avec un source déjà prévu pour debian:
tar -xzf /path/to/source.tar.gz
cd /path/to/source
dpkg-buildpackage -b -uc
et hop tu a ton fichier .deb dans le repertoire parent.
ou plus rigolo avec un source de debian:
apt-get -b source package-source
et hop c'est bon c'est fait.
Bein sur cela necessite par exemple un fichier .spec, .ebuild ou le dossier debian/ pour fonctionner. Mais tu decouvrira asser vite si tu veut faire ton interface que pas une personne n'utilise les confgure et autres makefile de la meme maniere.
C'est plutot utopique comme reve (et quand aux sources sans configure ou avec un configure qui ne detecte pas tout ce qui est necessaire ...)
[^] # Re: Idée du jour
Posté par Bruno Muller . Évalué à 1.
bin, ça existe déjà :
Package: auto-apt
Priority: optional
Section: admin
Installed-Size: 216
Maintainer: Fumitoshi UKAI <ukai@debian.or.jp>
Architecture: i386
Version: 0.3.20
Depends: libc6 (>= 2.3.2.ds1-4)
Recommends: apt, sudo, perl, wget, dpkg-dev
Suggests: x-terminal-emulator, libgtk-perl, build-essential
Filename: pool/main/a/auto-apt/auto-apt_0.3.20_i386.deb
Size: 45610
MD5sum: 1c04095554a0812cdaaea0a146296c8e
Description: package search by file and on-demand package installation tool
auto-apt checks the file access of programs running within its
environments, and if a program tries to access a file known to
belong in an uninstalled package, auto-apt will install that
package using apt-get. This feature requires apt and sudo to work.
.
It also provides simple database to search which package contains
a requesting file.
# Re: Idée du jour
Posté par neil . Évalué à 1.
alias superinstall='./configure --prefix=/usr && make && make install'
[^] # Re: Idée du jour
Posté par Cyberdivad . Évalué à 1.
J'ai du mal m'expliquer dans mon document (c'st vraimentun brouillon), mais regardez les deux exemples à la fin, ça sera plus clair à mon avis :-)
# Re: Idée du jour
Posté par ccomb (site web personnel) . Évalué à 1.
[^] # Re: Idée du jour
Posté par Alexandre Belloni (site web personnel) . Évalué à 1.
# Re: Idée du jour
Posté par ckyl . Évalué à 1.
Pour avoir packagé un nombre non negligeable d'applications dans des distros sources je peux te dire qu'il est inconcevable de faire un logiciel qui sache automatiquement tout compiler et gerer les dépendences. Déjà avec les les usines a gazes^W^W^Woutils GNU c'est bien le bordel (regarde des packages comme insight) mais je tu ajoutes a ca tout les softs qui n'utilisent pas les outils GNU et c'est pas réalisable comme projet ( a moins de monter une usines a gaze ^100).
Genre tu as la petite applis du style gtk2-ssh-askpass le spell sourcemage resultant est pour la compilation / installation :
(
sedit "s/gcc/gcc $CFLAGS/" Makefile &&
make &&
prepare_install &&
cp gtk2-ssh-askpass /usr/bin/ &&
if [ ! -e /usr/libexec/ssh-askpass ] ; then
ln -s /usr/bin/gtk2-ssh-askpass /usr/libexec/ssh-askpass
fi
) > $C_FIFO 2>&1
Je te met au défi de retrouver les libs qu'il utilise, et comment construire (le gars devait pas savoir faire de Makefile :-)
De plus comment tu gères les dependences de facon generique ?
Bref ce n'est absolument pas rationel étant donnée que le nombre de types de fichier en entrée est "infini" de même que les formats de sortie.
2/ C'est inutile
Celui qui compile son application doit savoir ce qu'il fait. Autrement qu'il utilise les packages de sa distribution. Je ne vois aucun interet a ce genre de chose. Si le gus est incapble de faire un less INSTALL && faire ce qu'il y a dit dedans je ne vois pas l'interet qu'il pourrait tirer de sa compilation. Hormis tout casser.
Si l'application n'est pas packagée le plus simple est d'envoyer un mail gentil sur la ml de dev de la distribution que tu utilises. Si l'outil interesse quelqu'un tu as de grandes chances d'avoir ton package dans la semaine.
3/ C'est deja fait
Ca s'appelle une distribution source. Et si pour le moment les packageurs n'ont pas été remplacer par des algorithmes il y a peut etre une raison...
Tu reinventes la roue en bordelique et pas très rationel quoi
cf: sourcemage
[^] # Re: Idée du jour
Posté par Cyberdivad . Évalué à 2.
Je vais peut-être devoir simplifier mon projet, au moins au niveau de la gestion auto des dépendances de compilation (libs, etc.), mais je continue à croire qu'il devrait être possible de réaliser au moins un front-end.
Celui qui compile son application doit savoir ce qu'il fait. Autrement qu'il utilise les packages de sa distribution. Je ne vois aucun interet a ce genre de chose. Si le gus est incapble de faire un less INSTALL && faire ce qu'il y a dit dedans je ne vois pas l'interet qu'il pourrait tirer de sa compilation. Hormis tout casser.
Le problème est qu'il arrive qu'il n'y ait pas le choix et qu'il faille partir du source.
- Parfois, les fichiers packagés, s'ils existent, sont trop anciens (il y a toujours un décalage entre la sortie de la dernière version stable et celle du package).
- Souvent, toutes les distribs sont loin d'être réprésentées (ce que je comprends, vu le boulot que ca entraîne).
- Ceux qui utilisent pour diverses raisons une version plus ancienne de leur distrib sont également bloqués.
- Si un logiciel est trop "petit", personne ne va s'embêter à faire des packages.
Quand à lire un fichier INSTALL, je le fais à chaque fois, et je trouve (sincèrement) que 80% d'entre eux sont incomplets ou faux (libs nécessaires erronées ou non listées, etc.)
Par exemple, il y a quelques temps, je cherchais des jeux de mastermind pour Linux/x11. J'ai trouvé une demi-douzaine de logiciels, mais j'ai pu en installer deux seulement si ma mémoire est bonne. Et pourtant, j'ai passé un temps honorable à mon gout pour essayer de compiler chacun d'entre eux. Si je ne voyais vraiment pas quel lib il pouvait bien me manquer, j'étais obligé d'abandonner. En plus, les deux que j'ai pu compiler, une fois que je les aie essayés, je me suis rendu compte qu'ils ne correspondaient pas à ce que je cherchais :-/
Pourtant, les libs utilisées dans un source, elles sont forcément spécifiées quelque part en clair non ? En c, par exemple, je colle des -lmachin au gcc. Un programme peut déjà analyser ça.
[^] # Re: Idée du jour
Posté par Boa Treize (site web personnel) . Évalué à 1.
[^] # Re: Idée du jour
Posté par ckyl . Évalué à 1.
A ouai mais non :-)
Le problème est que tu ne sais pas sous quelle forme se présente l'information. Faudrait avoir une analyse semantique tres (trop) poussée.
En fait que tu veux faire ressemble un peu a faire ce que faire un packageur a priori alors qu'un packageur le fait a priori et a posteriori.
Pour ma part, generalement je connais assez bien les dependences basiques des softs donc on commence par faire une première version. Une fois que le truc marche il y a un script shell qui essait de regarder si par hasard j'aurais pas oublié une dep, par exemple parsage de ldd pour un libxml ratée....
Tu peux aussi imaginer un logiciel en c qui fasse un system("perl xxxxx"). Ton programme pour fonctionner a besoin de Perl, mais cette info n'est dispo que dans le INSTALL ou dans le code.
> - Parfois, les fichiers packagés, s'ils existent, sont trop anciens (il y a toujours un décalage entre la sortie de la dernière version stable et celle du package).
C'est le problème d'une distrib binaire, commencer a tout recompiler n'est pas une solution.
> - Souvent, toutes les distribs sont loin d'être réprésentées
> - Si un logiciel est trop "petit", personne ne va s'embêter à faire des packages.
Faux si le logiciel est inutile personne ne va s'embetter. Generalement les packageurs sont curieux, et les applis sympas ne mettent pas longtemps a avoir un package utilisable (je ne dis pas forcement package officiel). Surtout s'il s'agit de quelque de pas enorme, pour sourcemage ou les spells sont tres facile a faire, en 4 minutes je peux te faire un spell installable (je ne parle pas de qualité la :-).
> Quand à lire un fichier INSTALL, je le fais à chaque fois, et je trouve (sincèrement) que 80% d'entre eux sont incomplets ou faux (libs nécessaires erronées ou non listées, etc.)
Dans ce cas basiquement du fait ./configure il t'insulte il te dit qu'il ne peut pas trouver libmachinechose et tu as juste a faire (apt-get install|urpmi|cequetuveux) libmachinchose(-dev ?). C'est le cas simple que ton prog a effectivement une chance de gerer. Mais un utilisateur un tout petit petit peu degourdi ne ferait-il pas exactement le meme chose ? Autrement encore une fois tout ce qu'il va faire c'est foutre le bordel sur sa machine.
> [ mastermind ]
Ton logiciel ne pourra rien contre les logiciels mal packagés. Par exemple on ne peut pas avoir Gnomemeeting 1.0 sur sourcemage pour le moment par ce qu'on est au moins 4 a s'etre peté les dents dessus... Alors qu'en le compilant a la main il n'y a pas de problèmes.
Un truc qui me semble plus interessant que ce que tu comptes faire serait d'adapter portage/sorcery/autre pour qu'il sachent gerer les dependences rpm/deb. C'est a dire de modifier la libdepends par exemple pour qu'il essait d'abord les methodes officielles de la distribution et d'utiliser tout le reste. Et la dessus tu peux facilement faire une interface graphique. Mais ce n'est plus ton logiciel qui fait le boulot des packageurs.
Enfin ce n'est que mon avis :-)
# Re: Idée du jour
Posté par xilun . Évalué à 1.
En plus y a tout le monde qui dit que c'est trop dur (et inutile mais sur ce point je crois qu'ils n'ont pas lu toute ta description), et je sais pas toi, mais moi les trucs trop dur a faire ca me motive bien :p
Je peux pas trop t'aider, mais bon courage :)
[^] # Re: Idée du jour
Posté par ckyl . Évalué à 1.
tu peux me pointer ce qui te semble etre interessant dans la chose ? J'ai surement raté quelque chose.
# Re: Idée du jour
Posté par Pierre . Évalué à 1.
waou.. pendant 2 secondes, j'ai cru que c'était un projet de grestion comptable..
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.