Posté par ckyl .
En réponse au journal Idée du jour.
Évalué à 1.
> 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.
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.
[^] # Re: Idée du jour
Posté par ckyl . En réponse au journal Idée du jour. É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 :-)