[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: knoppix ( limite hs !!! )



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



Reply to: