Re: Backport

[barbier@linuxfr.org (Denis Barbier)]

On Wed, Nov 21, 2001 at 10:25:35AM +0100, georges mariano wrote:
> On Tue, 20 Nov 2001 14:24:13 +0100
> barbier@linuxfr.org (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