Le jeu, 01/04/2004 à 13:59 +0200, Georges Mariano a écrit : > On Wed, 31 Mar 2004 10:52:13 +0200, Raphaël ""SurcouF" Bordet""" wrote: > > > Inutile de rappeler mon opinion sur les paquets rétro-portés... > > oui, c'est effectivement inutile. Car ton point de vue à ceci de > paradoxal que, vu que tu n'aimes pas la backport, tu n'en fais pas je > présume, ce qui ne t'empêche pas d'en parler de manière négative sans > vraiment en comprendre ni le fonctionnement (pur debian en fait) ni > l'utilité ...
A-t-on besoin d'essayer pour en discuter ? J'ai passé mes premières années sous Linux à gérer des RedHat. Là, tu n'avais pas d'outils comme apt et surtout une base de paquets si exhaustive et passer d'une version à une autre était un véritable sacerdoce. Cerise sur le gâteau: aucun support à attendre de la part de RedHat quant aux paquets rpm (quand on en avait) externes. > j'ajoute que si on trouve des arguments/raisons qui expliquent *par > l'exemple* en quoi le backport répond à un besoin utilisateur (ce qui > figure tout en haut du contrat Debian), j'ai encore pas vu d'argument > tangible contre (au sens mise en défaut du mécanisme même du > rétro-portage). Tout ce qu'on lit c'est le discours politiquement > formaté de ceux qui ont intérêt à ce qu'on reste scotché à une mise > à jour binaire (i.e boîte noire) des machines... Quel intérêt aurait-on ? Si tu as envie de développer une distribution annexe basée sur debian et permettant de faire du support sur des vieux paquets, sur une vieille base que tu ne veux pas changer, libre à toi. Le projet Debian subit des attaques aussi diverses que paradoxales. D'un côté, des utilisateurs de la stable qui voudraient avoir des fonctionnalités ou des versions qui n'existent que dans la distribution de développement et préfèrent les rétro-porter parce que le rythme des sorties ne leur convient pas. D'un autre côté, d'autres aimeraient avoir toujours les dernières versions des logiciels et des sorties plus rapides. Si le processus de publication du projet Debian ne plaît pas, il existe bien d'autres distributions Linux pour faire l'affaire: pour les premiers, une RHE est bien mieux indiquée, et pour les seconds, Gentoo me parait un meilleur choix. Maintenant, si tu as des suggestions crédibles pour améliorer le processus en question, je t'en prie mais argumente ton point de vue sans te prendre pour le centre du monde (cad tes besoins ne sont pas ceux de tous) Le processus de développement de la debian correspond à des critères de qualité et les rares problèmes majeurs en stable proviennent essentiellement de l'usage de paquets non-officiels et rétro-porté, sans parler des logiciels compilés à la main (comme Linux, par exemple). Est-ce que vous avez besoin de stabilité ou des dernières fonctionnalités ? Oui, supporter le matériel parait être une bonne raison mais en quoi le dernier cri en matière de matériel est-il nécessairement un critère de ...stabilité ? En aucune façon... > Le hasard fait que je viens de tomber sur un petit exemple bien > sympathique. J'espère qu'il est suffisamment simple pour que chacun pige > ce qui se passe. > * tout commence lorsque je m'aperçois que je n'ai pas installé > syslog-summary avec mon logcheck. > > * apt-get -s install syslog-summary -t stable => ok, 1 paquet v 1.11 > > * apt-get -s install syslog-summary -t testing => argh!! 19 paquets à > mettre à installer (dont gtkglarea5 iceme python xlibmesa3) pour avoir > la version 1.12 (notez au passage le saut phénoménal en version qui > justifie la mise à jour d'autant de paquets) [*] Oui, parce que tu n'utilises pas de testing et donc les paquets dont dépend ce paquet ne sont pas ceux de la stable. Maintenant, si tu vois des objections quant à la pertinence des dépendances, libre à toi d'en faire part de façon moins polémique au responsable. Il sera toujours prêt à entendre ton avis et tu as intérêt à bien argumenter. Et de telles remarques, j'en ai déjà fait: qu'elles soient suivies ou non, l'important est de discuter avec les développeurs: ils ne sont pas inaccessibles, loin de là et ce serait mieux de cracher dans la soupe (se plaindre publiquement du projet et, à la moindre contrariété, faire tout à sa sauce au lieu de participer à ce même projet). Dans ce cas précis, tu peux toujours chercher à discuter de la pertinence d'un champ "Provides: python-interpreter" avec eux. > * évidemment, il n'est pas nécessaire que syslog-summary dépende de > python dernier cri, je vous refait pas le coups du backport qui prend 2mn > pour avoir un paquet avec les dépendances correctes et qui s'installe > bien sur votre machine bien stable sans prendre le moindre risque (sauf > celui de casser syslog-summary, mais ça c'est normal) Rien ne t'empêche de le faire mais ne viens pas polluer le bts si jamais tu as des problèmes par la suite... Car la véritable question est bien là: comment supporter de tels paquets, pour le projet ? Impossible à faire pour les développeurs... Et surtout, ce serait bien plus de travail pour eux. > [**] oui parce qu'un message argumenté nécessite de passer du temps à > consulter les rapports de bugs, faire le backport, tester les mises à > jours (dans le chroot, en dehors du chroot), tester un peu le paquet > obtenu... Tout ce que l'on peut s'épargner par la phrase radicale mais > vide de sens : le backport c'est mal (DebianTM). Je ne limite pas ces recherches et autres consultations aux seules argumentations politiques et polémiques. Mais toi, tu considères que c'est une perte de temps... Les développeurs debian perdent leurs temps. Persister à vouloir te convaincre est une perte de temps: tu n'évolueras malheureusement jamais. > Aller, note finale d'"humour" : je vous laisse admirer le "bug" (clos!!) > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=171043 Ton humour est vraiment sarcastique... -- Raphaël 'SurcouF' Bordet [EMAIL PROTECTED]
