On Thu, Jun 19, 2003 at 12:20:53PM +0200, Thomas Nemeth wrote: > > Bon, je mets les pieds dans le plat, tant qu'� y �tre. > > > Le 19.06.03, Sven Luther a tapot� : > > | On Thu, Jun 19, 2003 at 08:55:55AM +0200, Jean-S�bastien Rousseau-Piot > wrote: > | > > | > Mon avis est que chaque portage devrait profiter des meilleures > | > outils de d�tection et de configuration disponibles, quitte � avoir > | > des installeurs diff�rents. > | > | Non, je ne crois pas que ce soit une bonne solution. La majeure partie > | de l'installateur est commune, ce qu'il faut c'est un installateur > | modulaire, ou chaque architecture fournirai les modules necessaire pour > | son architecture, tout en beneficiant du cadre commun. > > Oui. Mais il pourra�t aussi �tre simplifi� : les BSD, tout comme > Slackware, par exemple, utilisent un simple script shell. C'est > 100x plus facile � maintenir ! > Mais ce n'est qu'une piste suppl�mentaire : il est vrai qu'il > faut que ce soit un installeur commun modulaire en fonction des > archis...
Sur, mais est-tu sur que cela resoud le probleme de la convivialite ? > | > Plus il y aura d'utilisateurs convaincus, plus il y aura de > | > collaborateurs au projet. > | > | Si tout etait aussi simple, ce serait bien. Ce qu'il faut surtout c'est > | des gens qui se disent, je pense que cela serait mieux de cette maniere, > | qu'est-ce que je peut faire pour aider, et pas des gens qui se contente > | de crier, c'est nul, il faudrait pas faire comme cela, mais pourquoi > | vous ne fetes pas ceci a la place. Et encore, moi je suis patient sur > | ces points, d'autre developpeurs se contenterai de rediriger vers > | /dev/null toutes thread de ce genre. > > Le pb est que les personnes les plus � m�me de faire des > r�flexions _pertinentes_ sont ceux qui ont un minimum > d'exp�rience. Parmis ces personnes il y en a qui, comme Erwan > tant d�cri�, n'approuvent pas les choix faits par les DD (et > ce n'est pas en devenant l'un d'eux que cela changera les > choses) et sont envoy�s sur les roses... Et si ils partent de leur a priori sans reellement essayer de comprendre la situation, ou meme d'essayer de comprendre les choix existant. Dans ce cas, c'est un peu normal de les envoyes sur les roses. C'est comme si quelqu'un qui ne s'y connait pas forcement mieux que toi venait te dire que tout ton travail etait nul, qu'il fallait evidement pas faire comme cela, et que de toute facon, tu ne t'est pas attaque a la bonne priorite. Essaye de voir comment tu reagirai. Si c'est ton chef, et que tu est payer pour, ok, t'a pas d'autre choix que de faire avec, mais dans un cadre de volontariat, cela ne marche pas. > Tout n'est pas rose dans l'univers Debian et il est dommageable > que certains se fassent rabrouer parcequ'ils ont des opinions > particuli�res, principalement sous le pr�texte qu'ils ne sont > pas DD. Non, ils se font rabrouer parcequ'il essaye de donner des lecons sans vouloir faire l'effort de contribuer. Certe il y a un certains nombres de developpeurs irascibles, mais bon, c'est inevitables que cela arrive, et comme bon nombres d'entre eux effectue un travail souvent ingrat mais essentiel a debian, on les supporte et on pose les questions a d'autres plus ouvert. > Pour en revenir au pb soulev� par Erwan, les d�pendances, il faut > bien avouer que certains DD ont tendance � trop lier les > programmes qu'ils packagent et rares sont ceux qui offrent des > paquets sans toutes les biblioth�ques li�es... �a devient g�nant N'importe quoi. C'est pas les DD qui lient trop les programmes, c'est les systeme de build upstream qui le font, et dh_shlibdeps qui ajoute les dependances. Tu me dira il suffit de faire un package multi-binaire, avec une version simple et l'autre plus complete, mais cela represente plus de travail. Je suis sur que la majorite des developpeurs accepterait un tel patch, pourvu qu'il soit bien fait, et qu'il soit raisonable de le faire. > pour ceux qui ne veulent pas de tel ou tel truc et qu'ils se > voient oblig�s de l'installer pour pouvoir utiliser ce qui leur > plait -- ou ne rien installer... Ouais sur, mais il ne faut pas se focaliser sur ce probleme, et refuser d'installer tel ou tel librairie par pure caprice. > Bref pourquoi ne pas am�liorer aussi ce c�t� : �a fait des ann�es > que c'est un reproche d'une partie des utilisateurs avertis. Je ne > dis pas que c'est simple � faire : mettre des paquets avec plus ou > moins de liaisons n'est pas chose ais�e et prends de la place sur > les serveurs, mais bien fait (ie un paquet common/minimum + des > paquets avec uniquement les binaires link�s et des depends bien > plac�s) cela arrangerait tout le monde. Le seul truc posant pb est > la cr�ation de ces paquets : il devient n�cessaire de permettre > aux DD d'automatiser la compilation sous diverses formes de leurs > paquets. Sur, comme dis, les patches sont les bienvenus. > Maintenant ce n'est qu'une id�e parmis d'autres, libre aux DD ici > pr�sents d'en discuter parmis eux et de faire r�ellement �voluer > les choses... Voila, tu t'attend encore a ce qu'on fasse un travail qui n'est pas particulierement eleve dans nos ordre de priorite. Et cela, c'est quelque chose qu'il est tout a fait possible de faire en tant que non DD, tu en discute sur debian-devel (et accepte les flames qui vont suivre de maniere constructive), tu lis les docs nouveaux mainteneurs, tu propose des patchs aux packages, et tu en discute avec le DD en question. Si il est pas d'accord, re-discussion sur debian-devel, et eventuellement passage par le comite technique de debian qui tranche. Amicalement, Sven Luther
