Re: Subversion & debian 3 woody
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
surcouf@choranche.grotte.org
Reply to: