On Wed, Nov 28, 2001 at 12:36:52PM +0100, georges mariano wrote:
>
> 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.
Non, mais il est aberrant de l'exiger, alors qu'on ne sait pas comment
faire dans le cas g�n�ral.
[...]
> [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.]
Telle que je l'ai comprise, la solution des champs suppl�mentaires ajoute de
la complexit� sans apporter de r�el b�n�fice, puisqu'on peut faire la m�me
chose sans (avec des equivs ou en faisant des paquets multiples avec variantes
� partir d'un m�me source).
C'est la raison pour laquelle je demandais des �claircissements.
> > 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]
Euh, et �a montre quoi ?
> 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),
Oui.
> et ils ne se sentent (donc?) pas concern�s.
Tu extrapoles. L'�norme majorit� des d�veloppeurs est sur x86, et ils se
sentent concern�s par le bon fonctionnement sur d'autres architectures.
Le fait est qu'on ne sait pas comment faciliter le backport, et qu'il
faut donc attendre que quelqu'un s'en pr�occupe s�rieusement pour faire
une doc de r�f�rence qu'on puisse utiliser.
Le probl�me s'est je crois pos� de fa�on similaire avec le bug de l'an 2000,
c'est Vincent Renardias qui a fait quasiment tout le boulot tout seul.
Tout le monde �tait concern�, mais personne ne voulait s'en occuper.
> Or c'est eux qui d�cident de ce qui est mis dans la policy et pas les
> utilisateurs.
[...]
> 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
�a exclut d'office toute compilation sur hppa et ia64, qui n�cessitent
des fichiers config.{guess,sub} plus r�cents que ceux fournis upstream
dans la majorit� des cas.
Pour scigraphica, tu veux vraiment que le d�veloppeur Debian demande
� l'upstream si c'est une bonne id�e de modifier le Makefile.am pour
que les exemples n'aillent pas dans /usr/share/data/scigraphica/examples ?
Il va �tre mort de rire, l'upstream.
Pour les paquets faits de multiples composants (comme wml), certaines
parties sont d�j� des paquets Debian, et ne sont donc pas install�s.
Faut-il demander � l'upstream son avis sur la question ?
Il faut bien comprendre que la distribution par tarballs et par paquets
ont des contraintes diff�rentes, et l'upstream n'est pas toujours le mieux
plac� pour les appr�hender.
[...]
> ') 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.
Sur debian-devel, on n'est m�me pas d'accord sur la bonne fa�on de traiter
ce probl�me, alors ce n'est pas demain que �a sera dans la policy.
Mais le jour o� une solution est commun�ment admise, j'esp�re qu'elle
sera mise dans la policy ou le manuel du d�veloppeur.
> 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.
Non, cf les exemples ci-dessus.
�a signifie que c'est le mainteneur Debian qui d�cide de la configuration du
paquet, et que celle-ci est fig�e et n'est pas refaite lorsque le paquet est
recompil�.
Prends wml par exemple, je modifie la configuration de l'upstream, et il n'y
a aucune chance pour que les versions upstream et Debian convergent (je suis
l'upstream :)), parce que le tarball et le paquet Debian r�pondent � deux
besoins tr�s diff�rents.
Denis
