On Wed, 28 Nov 2001 11:15:22 +0100 [EMAIL PROTECTED] (Denis Barbier) wrote:
> Mais avant d'obliger le d�veloppeur � quoi que ce soit, est-il vraiment > aberrant de s'assurer que ce qu'on lui demande a un sens ? c'est ce qui est fait lorsque, en cas de p�pin, on v�rifie que le tarball recompile bien... la question est maintenant : est-il aberrant de demander � ce que le "apt-get source -b" fonctionne quand le tarball compile nickel ? je pensais que non. > Ensuite, quand ils savent que leur solution est viable, ils la proposent, Prenons un exemple pr�cis (qui couvrira �galement le cas des d�pendances minimales). Un peu de terminologie : une d�pendance est minimale (par rapport � une d�pendance initiale) si elle permet que l'installation affecte un nombre plus r�duit de paquets que celui induit par la d�pendance d'origine. Exemple : Soit un paquet A (sources r�cup�r�s dans woody) d�pendant de xlibs(-dev) Son installation(compilation) sur une machine potato induit l'installation de xlibs(-dev), i.e celle de xfree4, i.e le passage en woody de la machine, et donc bien d'autres mises � jour de paquets. Or, on constate bien souvent, que si on remplace cette d�pendance par une autre sur xlib6g(-dev), l'installation/compilation(et utilisation!!) du soft se passe sans probl�me sur une potato. En d'autre termes, le paquet "pr�tend" avoir besoin de xfree4 alors que ce n'est pas le cas. Il n'est donc pas n�cessaire de passer en woody i.e d'une install stable vers une install testing pour utiliser par exemple wmaker0.70. Dans ce cas, la d�pendance sur xlib6g est dite "minimale" (par rapport � celle sur xlibs) [En ce qui me concerne, je ne baserai pas la solution sur des champs suppl�mentaires dans debian/control. Des paquets dummies (produits par equivs) feraient l'affaire dans la majorit� des cas.] > Et je ne vois pas ce qui emp�cherait son adoption. Sur ce m�me sujet, apr�s en avoir discuter avec un autre d�veloppeur Debian, ce dernier, (dans le doute?), a poser la question suivante sur debian-devel en gros, faut-il mettre une dependance xlib6g(-dev)|xlibs(-dev) pour favoriser le backport ? Nombre de r�ponses : 0 (� l'�poque, � re-v�rifier). [malheureusement, ne me souvenant pas de la formulation exacte, je retrouve pas le message dans les archives, sauf erreur l'auteur �tait Sven Luther] Ce qui emp�cherait l'adoption ? Tr�s simple! La (grande) majorit� des d�veloppeurs sont en woody (d'o� l'insertion automatique d'une d�pendance sur xlibs et non xlib6g), et ils ne se sentent (donc?) pas concern�s. Or c'est eux qui d�cident de ce qui est mis dans la policy et pas les utilisateurs. > choses. Il faut donc modifier cette Policy, mais pour cela, > il faudrait avoir > des propositions concr�tes. ok. sur la question corollaire des chipos autoconf/configure pour la recompilation multi-archi (apparemment li�es � autoconf&cie), j'ai une proposition � faire : ) interdiction de modifier les configure, configure.in et autres fichiers de ce style (je suis pas expert) fournis par l'amont. si des corrections sont a fournir, il faut convaincre l'amont. => pas de r�f�rences � ces fichiers dans le diff des paquets sources (un peu comme il est demand� aux utilisateurs potato de convaincre les d�veloppeurs woody ;-) La policy indique d'ailleurs: "Whatever changes you need, always try not to fork from the upstream sources." ') variante (compl�ment) de la pr�c�dente. Il me semble avoir compris d'une discussion sur french-devel, qu'il ne devait pas y avoir d'appel � auto(make/conf/...) dans le debian/rules, alors l'indiquer dans la policy. Ce qui est une autre fa�on d'exprimer que c'est l'amont qui d�cide du contenu de la phase d'autoconfiguration du paquet. '') (je suis lanc� :-) autant que possible l'impact Debian sur ces points doit �tre localis� au Makefile(.in) et aux options d'appel de configure (tjrs dans debian/rules). A+ -- # mailto:[EMAIL PROTECTED] tel: (33) 03 20 43 84 06 # INRETS, 20 rue �lis�e Reclus fax: (33) 03 20 43 83 59 # BP 317 -- 59666 Villeneuve d'Ascq # http://www3.inrets.fr/estas/mariano
