On Wed, 21 Nov 2001 13:03:07 +0100 [EMAIL PROTECTED] (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:[EMAIL PROTECTED] 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
