Selon Patrice Dumas
> Peut etre que je me trompe mais j'ai l'impression que ca ne devrait pas
> etre dans les scripts d'eagle-usb que se passe tout ceci, car c'est
> trop distro dependant et ca devrait etre dans les packages. A la limite
> mettre un switch pour configure, peut etre.
L'introduction de "BOOT_METHOD" par Tux est une très bonne idée.
C'est mieux : avant c'était pareil mais le code était mieux disséminé.
Selon Tux
> Pour les packages, tu parles des RPMs et cie? Vu le nombre
> de distribs et de noyaux, on ne peut gérer qu'une partie infime
> des possibilités.
C'est vrai. Mais c'est aussi un argument pour nous encourrager
à laisser plus de travail aux empaqueteurs.
> Pour la config manuelle, c'est une régression puisque pour l'instant
> tout est (censé) être fait automatiquement.
Complètement d'accord. Tout retirer brutalement génerait énormément
les utilisateurs. En revanche il faudrait peut-être réfléchir
à quelques possibles « transferts de compétances ».
> > Et tout ce qui devrait etre fait est de mettre dans un README
> > "des scripts de demarrages sont dans utils/scripts/, vous pouvez
> > choisir celui correspondant à votre distribution". Et l'utilisateur
> > sait s'il doit utiliser chkconfig ou autre chose.
> Avec le démarrage au boot, eagleconfig n'est pas en doublon avec la distrib
> elle même vu qu'il ne fait que lancer chkconfig sur Mdk par exemple. Je vois
> pas trop où tu veux en venir...
C'est intéressant lorsque les actions à accomplir sont réellement très
différentes selon les distribs. Et cela simplifierait grandement notre
travail.
Mais je pense aussi que c'est vraiment une bonne chose
qu'eagleconfig propose le démarrage au boot.
J'en profite pour rappeler une idée de fonctionnalité : le démarrage
au branchement du modem.
> > Ainsi, dans eagleconfig il ne devrait pas y avoir la question du style
> > "voulez vous demarrer la connexion automatiquement au boot", ca
> > devrait etre le travail de l'outil de paquetage.
> Ce serait trop compliqué pour l'utilisateur.
> Sous Mdk, il va s'amuser avec des chkconfig, sous slack à changer les
> droits d'accès du script de boot....
> Bref, vraiment pas pratique.
À mon sens, c'est une erreur de vouloir faire un tarball
« facile à installer ». Il serait préférable de faire un tarball
flexible qui permettrait aux empaqueteurs de faire des paquets
faciles.
L'utilisateur qui installe Linux en ne sachant pas comment ça
marche et qui ne veut surtout pas le savoir, ne veut pas non plus
utiliser un tarball (configure; make; ...)
> > D'ailleurs je pense qu'a terme il ne devrait pas y avoir de DISTRIB=
> > dans les scripts, tout ce qui est distrib dependant devrait etre dans
> > les scripts de package et quelqu'un qui installe en utilisant le
> > source doit etre capable de faire ce qui est distrib dependant a la main
> > (eventuellement avec un peu d'explications dans un README).
> Comme je l'ai déjà dit, les paquetages ne peuvent pas être notre méthode de
> distribution principale.
Mais ça doit le devenir.
> Il y a trop de problèmes à gérer entre les différentes versions du
> driver eagle (changement d'emplacement pour les scripts, de méthode
> de fonctionnement...). En plus avec les multitudes de noyaux qui
> se baladent, je vois pas trop comment on pourrait faire.
> Souvent sur la ML, on demande aux gens de prendre les sources, voir de tester
> le CVS. Même s'ils n'y connaissent rien, ils arrivent à lancer ./autogen.sh
> && ./configure && make uninstall && make && make install && eagleconfig.
> Donc, je ne m'avancerais pas à faire le parallèle "utilisateur qui compile le
> driver" & "utilisateur qui maîtrise sa distrib"
Ce sont des vrais raisons. Mais pour moi c'est un manque de maturité
du développement du driver. Le temps (notre travail ?) devrait enlever
ces problèmes.
D'ailleurs sans vouloir jouer les rabat jois, je signale que le respect
de toutes les normes seraient une avancées énormes (en particulier
Filesystem Hierarchy Standard).
> > Qu'est ce que vous en pensez ?
> Bon, désolé si je suis sur la défensive!
Moi je suis d'accord en partie avec Pat.
Et pour appuyer ma pensée je donne un exemple précis :
> # extrait de eagleusb/configure.in
> if test "x${prefix}" = "xNONE" ; then
> # on SuSE, default root path doesn't contains /usr/local/sbin
> # on Mandrake, graphical tools require the scripts to be in /usr/sbin
> if test "${DISTRIB}" = "Mandrake" || test "${DISTRIB}" = "Suse" ; then
> prefix=/usr
> else
> prefix=/usr/local
> fi
Visiblement Suse considère que le root doit éditer lui même son PATH
s'il met des programmes dans /usr/local. C'est un choix et c'est pas
notre problème.
Et il me semble naturel que l'installation d'un programme local
(c'est-à-dire compilé par les soins de l'administrateur) ne soit
pas pris en compte automatiquement par les outils de Mandrake.
Même s'il me semble préférable de garder le fonctionnement actuel
pour l'instant, il faut reconnaître que ce n'est pas « normal ».
mcoolive
