Re: Backport

[barbier@linuxfr.org (Denis Barbier)]

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.

Il m'est arrivé récemment de fournir un paquet avec une dépendance qui
empêchait la compilation sur Potato. Quelqu'un me l'a signalé et j'ai
corrigé, mais si cette personne avait commencé par me gueuler dessus,
il est probable que je ne l'aurais pas fait aussi vite.

> Donc je place en tout premier lieu le principe __simple__ suivant :
> si je peux, sans modifier ma machine, utiliser le tarball  upstream
> mais que le paquet Debian lui exige des modifs (i.e installation ou
> mise à jour d'autres paquets), je suis en droit de m'en étonner.
> (je suis pas sorti du troupeau windows pour entrer dans un autre)

Même réponse, tu t'étonnes si tu veux, mais le paquet que tu as entre
les mains est fait pour être compilé sur unstable, rien ne garantit
qu'il compile correctement sur Potato.

> Ensuite, je place un second principe, qui est le suivant, c'est que
> s'il existe une bonne raison pour modifier de manière notable
> la manière dont se compile et s'installe une appli, 
> je veux bien le comprendre (si j'en ai envie ;-),

Ah ? Dès que je te fournissais une explication sur un paquet, la seule
chose qui t'intéressait est d'en trouver un autre pour lequel tu
pourrais enfin dire que le responsable Debian est en cause. Il ne m'a
pas semblé que la compréhension du problème sous-jacent était pour toi
le but de la discussion.

> mais en tout état de cause c'est au  développeur upstream de prendre cette
> décision.

Ben non. Les développeurs Debian sont tenus de respecter la Policy, ce
qui peut impliquer des changements dans les sources, alors que le
développeur upstream peut n'en avoir rien à secouer.

> Maintenant, et j'ai pas envie de rentre dans les détails techniques
> car ce n'est pas un sujet technique mais plutôt un sujet "méta", si
> pour une raison estimée bonne, le processus de packaging Debian
> court-circuite ces principes, soit. Mais je préfère avoir conscience
> du fait que, ce faisant, je récupère une version "divergente" de la
> version upstream.

Très bien, à partir d'aujourd'hui, tu es prévenu : les paquets que tu
installes sont susceptibles d'être modifiés par rapport à la version
upstream.

> Et on a beau lire les diffs et autres changelog, en général ça
> raconte _ce_ qui est fait mais rarement le __pourquoi__ c'est fait.
> Cela reste à la charge de l'imagination du lecteur, s'il en 
> a vraiment envie.

Exact. Mais je croyais que tu étais motivé pour comprendre le pourquoi,
alors un peu d'exercice ne peut pas faire de mal.

> Dans ce cas précis, je voudrais que quelqu'un nous explique pourquoi
> (et si possible de manière compréhensible)
> le mainteneur debian passe à autoconf2.52 (ce qui pose problème
> en particulier pour installer sur une potato) alors que le
>  développeur upstream n'en a pas besoin (et donc cela s'installe
> sur une potato)?

Ça va être dur, scigraphica ne demande pas autoconf2.52 pour compiler.
Ton problème vient certainement d'une des bibliothèques que tu as
backportées.

> ou alors qu'on me dise en quoi les principes simples ci-dessus
> ne tiennent pas la route...et donc pourquoi le packaging debian
> ne respecte pas nécessairement le fait que le tarball soit compilable
> sur une machine donnée

J'ai bon ?

Denis