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

Re: Backport



On Wed, 21 Nov 2001 13:03:07 +0100
barbier@linuxfr.org (Denis Barbier) wrote:

> > 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.
plutôt certains utilisateurs potato, à mon avis...

> 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, 

Faudra que tu dise ça à ceux qui ont récupérer chez moi des paquets
de soft récents et mis ça sur leur patate sans problème notable.
(des trucs style enlightenment par ex)
Compare ensuite avec une mise ajour potato/woody...

> 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.
et c'est toi qui me parle d'utilisation détournée parce que je fais
tout pour utiliser des paquets debian sur une machine debian 
à la mode debian ??????

> > [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.

> 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

Désolé, que je sache les développeurs sont (j'espère) aussi conscients
que les utilisateurs de ce problème de release. 
Si néanmoins, ils ne "souhaitent" pas en tenir compte dans leur
réflexion sur la politique concernant les dépendances entre paquets,
Si par ailleur ils décident de privilégier le nombre d'architecture
quitte à prendre des risques sur la compilation des paquets (en
particulier parce qu'ils se posent un problème qui serait plutot du
ressort upstream)
Encore une fois,désolé, mais c'est pas moi doit être blamé parce que
je souhaite privilégier avant tout la stabilité de mes machines
potato.
Et si parler de ça, c'est "mettre en cause" les développeurs,
c'est pas mon problème ... c'est le leur.

> 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. 
ben voilà, Denis, c'est ce que disais...

> 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 comprends bien que ça va faire joli dans la pub Debian, mais
mon avis est que ce faisant, Debian se donne un objectif qui n'est 
même pas celui des développeurs upstream, et donc on va nécessairement
au devant de difficultés voire incompatibilités (inutiles)

> Je trouve que cette attitude reflète un très grand respect des
utilisateurs,
c'est marrant moi, utilisateur, j'ai l'impression exactement inverse.

> et je suis heureux qu'il ait choisi cette solution plutôt que la
solution
entre développeurs heureux, vous pourriez vous faire une petite bouffe
alors
j'ai déjà une histoire drôle pour égayer la soirée,  celle de
l'utilisateur
potato qui essaye d'installer scigraphica ...
oui Denis, je sais, on parle pas du même cas, mais je vois d'ici la
scène :-)

> de facilité qui consisterait à exclure les architectures qui posent
problème.

quitte à bidouiller la compilation spécifiée par upstream, 
quitte à ne plus permettre l'installation sur une potato "normale",
quitte à mettre en danger la stabilité lors de l'upgrade (devenue au
passage
quasi obligatoire)...

je n'ai fait que "quelques années" d'études informatiques, mais c'est
une conception de la stabilité comment dire ... ah oui, 
un peu détournée ;-)

PS : 
je suppose que le binz actuel dans les paquets python debian 
(renommage/redécoupage entre potato/woody) qui fait
que le backportage de scigraphica est bloqué, (j'arrive pas à mettre
la main
sur un paquet source de python1.5-numeric) ne peut être imputé aux 
développeurs ... il a été décidé et mise en oeuvre par le
saint-esprit...
Même le mainteneur du paquet semble s'y être perdu... et le pauvre, je
le comprends.

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: