Re: propositions [était : disgression]
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.
> 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:Georges.Mariano@inrets.fr 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
Reply to: