On Wed, Nov 21, 2001 at 10:25:35AM +0100, georges mariano wrote:
> On Tue, 20 Nov 2001 14:24:13 +0100
> [EMAIL PROTECTED] (Denis Barbier) wrote:
>
> > On Tue, Nov 20, 2001 at 12:55:30PM +0100, georges mariano wrote:
> > [...]
> > > Ma d�marche est purement "utilisateur du syst�me de packaging
> Debian"
> > > (syst�me qui se place entre moi et les applis upstream).
> >
> > Et o� as-tu vu que le syst�me de packaging Debian �tait pr�vu pour
> �a ?
> > Tu en fais une utilisation d�tourn�e, alors il ne faut pas t'�tonner
> > d'�tre confront� � certains soucis.
>
> avec bientot une dizaine de machines debian en utilisation et donc
> probablement un "paquet de paquets" install�, je suis plut�t
> satisfait de mon "utilisation d�tourn�e"... mais merci de m'en avoir
> averti, je vais faire gaffe dor�navant
>
> Pour toi la notion de backport est donc une utilisation d�tourn�e ?
Oui.
Ce n'est que mon avis, d'autres d�veloppeurs en ont peut-�tre un diff�rent.
> ok, alors comment appeles-tu les choses suivantes :
>
> - [cas g�n�ral] devoir aller chercher dans une distrib �tiquet�e
> "testing" voire "unstable" les derni�res version de softs largement
> consid�r�s (et disponibles) comme stables par ailleur?
C'est d� au temps �coul� entre 2 releases, qui est largement trop grand.
Mais tu contournes ce probl�me avec une solution inadapt�e, alors pourquoi
t'�tonner que ce que tu fais ne marche pas comme tu voudrais ?
> - [cas particulier] devoir piocher dans unstable le paquet
> scigraphica, (non dispo testing) puis dans testing le paquet
> python1.5-numeric (non dispo dans unstable) si on veut avoir une
> chance d'installer scigraphica...
>
> - ... qui de toute mani�re est compilable sur une potato
> (je peux vous envoyer une copie d'�cran??).
Je ne pratique pas autant le backport que toi, mais quand je le fais, je
pr�f�re compiler le tarball original et l'installer dans /usr/local.
> [faire abstraction du fait que le paquet d�pende de xlibs >>4.10]
> Au passage, Denis, ceci est un exemple de d�pendance non minimale
> �voqu� par PK, que tu as tellement de mal � comprendre.
Et oui, j'ai du mal, et ce n'est des indications �vasives qui vont m'aider.
Si tu me fournis le fichier debian/control tel que tu voudrais qu'il soit
pour un cas particulier, �a serait d�j� beaucoup plus clair.
> Admettons que pour avoir des machines debian utilisables et � jour,
> je fasse un "usage d�tourn�" du syst�me Debian, � ton avis,
> on y est pas un peu pouss�, tu trouves pas ?
Oui, le temps �coul� entre 2 releases est beaucoup trop important,
et c'est un vrai probl�me. Mais consid�rer que les d�veloppeurs des
paquets que tu n'arrives pas � backporter sont en cause n'est pas
juste.
> > Ton probl�me vient certainement d'une des biblioth�ques que tu as
> > backport�es.
> Bien s�r. Tu vas nous expliquer comment et pourquoi, sur une machine
> qui ne connait m�me pas l'existence d'autoconf2.52, j'ai ins�rer des
> fichiers qui en d�pendent ? ou alors ce serait � l'insu de mon plein
> gr�s ...
> Moi, dans le changelog de scigraphica je vois une info 2.52, certes
> �a parle de configure.in, mais y'aurait pas comme un rapport ??
> "* configure.in: - Add AC_PREREQ(2.52)"
> (je crois comprendre que le configure utilis� est g�n�r�
> par autoconf2.52)
Mea maxima culpa, j'avais la version pr�c�dente 0.7.1-5, d�sol�.
C'est _dans ce cas_ une connerie du d�veloppeur, qui ne sait pas g�rer
la compilation via autoconf/automake. Il suffit de lui expliquer via un
rapport de bogue pour qu'il fasse les choses correctement.
Tu devrais pouvoir contourner ce probl�me en mettant ces lignes avant
l'appel � configure dans debian/rules :
find . -name aclocal.m4 -exec touch {} \;
find . -name Makefile.in -exec touch {} \;
find . -name 'stamp-h?.in' -exec touch {} \;
find . -name configure -exec touch {} \;
(je ne dis pas que c'est la solution que le d�veloppeur du paquet doit
utiliser, mais c'est la solution la plus simple pour toi).
> et puis �galement
> "* config.sub, config.guess, ltmain.sh: Replaced with the newest
> ones."
> de quoi je me m�le ??
>
> question : si le tarball n'a pas besoin de ces modifs, � quoi
> correspondent-elles ? (�ventuellement dans la policy alors ?)
>
> c'est toujours la question � laquelle tu n'as pas r�pondu.
Si, j'y ai r�pondu sur snmpkit, dans ce cas l�, les changements avaient
�t� faits pour permettre le portage sur des machines non x86.
Tu avais r�pondu :
> bon maintenant, si on est pret a "sacrifier" un paquet qui compile bien pour
> une archi pour avoir une chance de recompiler pour d'autres, c'est un point
> de vue... qu'�videmment je partage pas ... mais bon quel importance !?
>
> PS : Une remarque, j'extrapole hein;-), supposons que upstream ne se soucie
> pas des autres archis d'o� le probl�me (pour l'instant virtuel!), pourquoi ce
> serait au mainteneur de Debian de s'en soucier au risque de l�ser les
> utilisateurs "pr�vus" par upstream ??
Il n'est pas oblig�, il peut tr�s bien d�cider d'exclure des architectures
s'il ne veut ou ne sait pas faire les changements n�cessaires au portage.
Dans le cas de snmpkit, le mainteneur a supprim� un test qui ne compilait pas
sur certaines architectures car cod� n'importe comment, et qui n'a aucune
influence sur le fonctionnement de la biblioth�que.
Voil� pourquoi il a choisi de modifier src/Makefile.am (de m�moire) afin
que cette biblioth�que, dont la compilation est bloqu�e sur certaines
architectures � cause de fichiers non utilis�s, puisse �tre diffus�e sur
le maximum de plate-formes.
Je trouve que cette attitude refl�te un tr�s grand respect des utilisateurs,
et je suis heureux qu'il ait choisi cette solution plut�t que la solution
de facilit� qui consisterait � exclure les architectures qui posent probl�me.
Sa solution n'�tait pas parfaite, puisqu'il y avait des soucis de d�pendances
de certaines versions d'auto*, et suite � un rapport de bug que j'ai envoy�
� ce moment l� pour lui demander des explications, il m'a indiqu� en priv�
qu'il va faire son possible pour uploader un nouveau paquet sans ces
d�sagr�ments. S'il ne l'a pas fait, tu peux envoyer un message sur le m�me
rapport de bug en lui demandant quand il va le faire. C'est
http://bugs.debian.org/117289
Denis
