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

Re: propositions [était : disgression]



On Wed, Nov 28, 2001 at 12:36:52PM +0100, georges mariano wrote:
> 
> On Wed, 28 Nov 2001 11:15:22 +0100
> barbier@linuxfr.org (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



Reply to: