Re: backport Imagemagick
Patrice Karatchentzeff (2001-10-24 15:44:35 +0200) : Bah, la réponse est toujours la même : quand tu gères un parc de machines en production, tu ne peux pas faire n'importe quoi dessus. L'approximation et le débogage n'ont pas leur place. Dès-lors, le choix de Potato s'impose obligatoire (C'est Debian qui parle de stable...) et donc, corrolairement, le back-port pour tous les logiciels plus à jour... Oui, bon, certes, mais je ne vois pas en quoi recompiler un paquet de testing pour stable le rend stable. S'il est buggué dans testing, il le sera tout autant dans stable. Et en plus, le recompiler dans stable risque d'introduire de nouveaux bugs parce que le package n'a pas été prévu pour tourner sous stable. Soit c'est des bugs cachés (par exemple une dépendance non exprimée ou mal exprimée sur une version particulière d'une bibliothèque), soit c'est pas des bugs. Genre, un package pour Woody s'attendra à trouver des fichiers à un endroit précis (parce que la Policy de Woody est ce qu'elle est) et que ces fichiers n'y seront pas en Potato (parce que la Policy n'est pas la même). Pour moi, le backport risque d'introduire plus de problèmes qu'il n'en résoudra. testing est bien pour les courageux (et les moins courageux) mais cela reste du test, ce qui la condamne en production¹. Et faire confiance à un système non testé, potentiellement non cohérent, c'est pour les peureux ? ¹: tu trouveras toujours des gens pour me contredire (testing stable, au moins autant que telle ou telle distribution) mais lorsque tu connais les grosses entreprises, tu ne rigoles pas avec ce genre de principe. La stabilité *est* le critère absolu dans ce genre de démarche. Aucun problème sur ce principe. Mais je ne suis pas convaincu que Potato+backports soit tout le temps plus stable que testing. Potato tout court, stable comme un roc, OK. Mais des backports... Roland. -- Roland Mas - Ogenki desuka, yau de poêle ? - Genki desu, ture en zinc.
Re: backport Imagemagick
Le Wed, 24 Oct 2001 16:23:01 +0200, [EMAIL PROTECTED] écrivait : Aucun problème sur ce principe. Mais je ne suis pas convaincu que Potato+backports soit tout le temps plus stable que testing. Potato tout court, stable comme un roc, OK. Mais des backports... C'est vrai pour des paquets sensibles (libc, X, etc.). Pour du tout venant (Imagemagick ici), ce n'est pas un problème. Cela reste une potato avec des paquets « utilisateurs » mis à jour. Donc, au pire, ce qui risque d'être instable sont les paquets « utilisateurs » qui ne doivent pas interférer avec le système (au sens où un seg fault paralyserait la machine). Si l'on doit changer un paquet critique, il faut *sérieusement* se pencher sur la question (passage ou non à testing (via bien sûr une mise à jour purement graduelle comme le souligne Jérôme)). PK -- Patrice KARATCHENTZEFF STMicroelectronics Tel: 04-76-92-67-95 850, rue Jean Monnet 38926 CROLLES Cedex, France Courriel: [EMAIL PROTECTED]
Re: backport Imagemagick
On Wed, 24 Oct 2001 15:00:37 +0200 (MEST) Jérôme Marant [EMAIL PROTECTED] wrote: JMTu es en train de backporter le monde Georges ? ;-) vi... on va me surnommer Atlas ... ;-) JMPourquoi ne passes-tu pas à testing plutôt que te donner tant JMde mal ? Euh, qui t'as dit que j'avais du mal ... Imagemagick c'est un paquet sur ... un peu plus de 326 ... :-) Pourquoi ?? Réponse : pourquoi pas ?? Plus sérieusement, pour le principe ! Si Debian se dit stable (et je demande qu'à le croire) ce doit être raisonnablement faisable... Si ça ne l'est pas alors y'a un blême ... Et le plus important : c'est inimaginable les trucs qu'on apprend en faisant ça... C'est imparable pour la qualité des paquets... Petit exemple : la recompile de imagemagick bloque entre autres parce que a) il exige une lib qui en définitive est optionnelle b) il oublie de demander une lib qui elle est (apparemment) indispensable c) ce problème de install_vendor d) après avoir mis la valeur site, on va un peu plus loin... ça bloque à nouveau ... veut installer des trucs dans debian/usr/lib/perl5/... qui n'existe pas ... N'importe quoi. PS : Dans l'intervalle de nombreux messages très significatifs ... Juste deux choses (c'est un peu méchant mais bon...): 1- Le seul qui ai vraiment compris _tous_ les paramètres du problème c'est PK. 2- A part ça bcp d'approximations... ai-je dit que j'upgradais aveuglément tous ce que je backporte (plus pour le fun d'ailleur...) ? Pour me convaincre de passer en woody, précipitez-vous pour répondre à la question suivante : a) qu'on m'explique pourquoi je vais (prendre le risque non négligeable de) rendre inutilisable ma petite dizaine de machines parce que je vais pointer sur woody et que, quasi inévitablement, ça va me chambarder les serveurs X, les install perl, tout ça pour que mes utilisateurs, qui se pointent tous les matins au boulot (détail non négligeable), utilisent la dernière version d'une appli tout venant reconnue stable upstream, et qui n'à que faire de la policy-à-la-mode-actuellement ? b) une de plus tiens, pour la route... si le paquet source pris dans woody recompile pas ... d'où vient le paquet binaire correspondant ??? Je ne vous donnerai pas la liste des paquets qui soit disant nécessitent woody et qui fonctionnent bien sur mes potato depuis longtemps. Et qui se recompile sans un problème simplement en faisant croire que je suis en Xfree4 (merci equivs) Pour conclure, faudrait peut-être se rendre compte un jour que ce qui est 'unstable' chez Debian c'est _surtout_ les décisions humaines Debian, et pas les bugs des applis, ni la recompilation du tarball (90% de la validité du package)... On en vient à ne pas pouvoir installer un paquet pour des raisons administratives et non techniques... Faut arréter de délirer sur vos destriers blancs étiquetés Debian (ça rime!)... Je crois pas que ce soit la faute de ImageMagick si le paquet que je récupère ne se compile pas. ça vient de me donner une idée horrible ... je remonte d'un grand... make install (i.e install à la tarball)... et ça marche !! display 5.3.8 en potato... dernière fois que je fais ça.;-) Parait qu'il y a une équipe assurance qualité chez Debian ?? Fallait pas m'énerver ... ;-) 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
Re: french : une d�cision � prendre
Comme je l'avais déjà signalé à Nicolas, il est possible de contourner le problème en mettant LANG=fr_FR* LC_ALL=french dans /etc/environment. Malheureusement je ne l'ai testé que sur modconf qui est bien repassé en français, mais n'ai pas essayé sur tasksel et les autres outils possibles mais je présume que cela doit fonctionner. C'était une idée comme une autre - Original Message - From: Denis Barbier [EMAIL PROTECTED] To: debian-devel-french@lists.debian.org Sent: Wednesday, October 24, 2001 6:44 PM Subject: Re: french : une décision à prendre On Wed, Oct 24, 2001 at 05:02:57PM +0200, Nicolas SABOURET wrote: [...] Laquelle ne considères-tu pas comme du bidouillage ? Je rappelle : 1. Pas d'alias. Mettre fr_FR.ISO-8859-15 dans language-env et dans les instructions du doc debian en français 2. LANG=fr modconf 3. Demander aux mainteneurs de tester le fichier alias. Si c'est 1, pourquoi avoir un fichier /etc/locale.alias ? Et justement, les anglais et les américains vont continuer à se taper dessus parce qu'ils n'ont pas compris qu'il suffisait de changer la ligne english de ce fichier pour avoir l'anglais de chez eux. Si c'est 3, cela signifie contacter chaque mainteneur pour qu'il utilise le fichier alias ... (rêvons un peu, ça fait du bien). Oui, c'est celle-là qui semble la plus normale. Qu'ils aient un mode dégradé sans locales pour l'installation, pourquoi pas, mais après il faudrait quand même utiliser les locales. Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] __ ifrance.com, l'email gratuit le plus complet de l'Internet ! vos emails depuis un navigateur, en POP3, sur Minitel, sur le WAP... http://www.ifrance.com/_reloc/email.emailif
Re: [EMAIL PROTECTED]: Requirements for a system with translated package descriptions]
Le Tue, 23 Oct 2001 11:59:53 +0200, Martin Quinson [EMAIL PROTECTED] a ecrit: Hello, Grisu vient enfin de mettre en ligne le document spécifiant ce que le système de traduction des descriptions de paquets doit permettre du point de vue de l'utilisateur. On ne parle pas de comment le faire (c'est le boulot des développeurs dpkg), mais de ce qu'il faut faire. Grisu n'a pas préciser où on en cause. Je dirais si vous etes faché avec l'anglais, ici meme, et sinon sur -i18n. On ira sur -dpkg quand on aura un document final et qu'il faudra parler d'implementation (et encore. Si on nous y invite). Les discutions sur -i18n ont été un peu minimales jusque la. Veuillez commenter ce document pour que cette idée ne s'embourbe pas (trop/plus)... To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] Bonjour, Malgré que je suive l'affaire en parfait dilettante (ce qui veut dire que je ne suis pas spécialiste du sujet, mais qu'il est possible de ce fait que je puisse avoir des idées intéressantes/nouvelles à proposer - je ne serais d'ailleurs pas le seul ici, il doit y avoir bien d'autres personnes dans ce cas), j'aimerais apporter ici ma contribution à l'affaire. J'ai auparavant jeté un léger coup d'oeil aux archives de -i18n et -devel pour m'immerger un peu dans cette histoire (et ce bien que mon anglais soit très approximatif). Il m'a semblé y avoir quelques bonnes idées, mais aussi beaucoup de blablas qui ne font beaucoup avancer les choses. Je me trompe peut-être. Bref. J'écris surtout ce message pour savoir s'il serait possible de reprendre (dans une certaine mesure) les choses sur des bases saines afin de commettre quelque chose que les habitués/aguerris de -devel pourraient transmettre ensuite à la partie anglophone. Question préalable : Est-ce possible? En supposant que la réponse soit positive, je poursuis. D'après ce que j'ai compris, il s'agit donc de traduire les descriptions de paquet ; j'ai bon là? (la chose dans debian/control, vrai?). Bien. La première chose qu'il me semble bon de définir c'est une liste pour avoir sous les yeux le ou les buts à atteindre (encore un fois, je parts sur le principe que je n'y connais pas grand chose, et donc que je n'ai pas encore d'éléments pour amener de bonnes réponses - les plus proches de la vérité possible évidemment...). Je vais construire petit à petit une liste de questions, à qui j'espère donner au fur et à mesure des réponses. Il faudrait ensuite faire un tri, les classer, en deduire certaines choses, etc. Ainsi, pourrons-nous, je l'espère, dresser quelque chose de transmissible à -devel (ou tout autre). Essayons d'être constructifs. (si c'est pas au beau défi ça...). Cette liste va donc être _très_ incomplète. Les questions ne sont peut-être pas les bonnes, les réponses peuvent être uniques, multiples, exclusives ou non, etc. On démarre doucement La méthode vaut ce qu'elle vaut, mais elle ne me semble pas mauvaise. J'ai peut-être tout faux. Peut-être même que vous allez trouver cela totalement saugrenu. Tant pis. Au moins, j'aurais essayé. Donc (enfin...) : - Nous avons des paquets. - Nous avons des descriptions dans ces paquets. - Nous avons des langues. - Nous avons des mainteneurs. - Nous avons des traducteurs. - QU'EST CE QUE NOUS N'AVONS PAS? - (1) Les descriptions traduites. - QUE FAIRE POUR AVOIR (1)? - (2) Traduire les descriptions. - (2), QU'EST-CE QUE CELA FOURNIT? - (3) La traduction de description. - QUI EFFECTUE (3)? - (4) Le traducteur. - (5) Le mainteneur. ... - QUE DEVIENT (3)? - (6) intégrée dans le paquet (control) - (7) (autre?) ... (Oui, c'est un peu tiré par les cheveux, simpliste, inutile, etc. Suite...). Voici en dernier lieu ce qui peut-être une liste fruit des questions précédentes : - CE QUI DOIT ETRE FAIT PAR LES MAITENEURS - (6) intégrer les descriptions dans le paquet. - ... -- COMMENT LE FAIRE? AVEC QUOI? - ... - CE QUI DOIT ETRE FAIT PAR LES TRADUCTEURS - (2) Traduire les descriptions. - Transmettre les descriptions aux mainteneurs. - Ne pas transmettre les descriptions aux mainteneurs. - ... -- COMMENT LE FAIRE? AVEC QUOI? - ... - CE QUI DOIT ETRE FOURNIT AUX UTILISATEURS : - (1) Les descriptions traduites - La ou les description(s) de base au cas où (1) indisponible. - ... - CE QUI DOIT ËTRE FAIT SUR LES OUTILS (DPKG? AUTRES?) - Reconnaître la langue de l'utilisateur? - Reconnaître les langues de l'utilisateur? - Définir une langue de secours? Des langues? - ... C'est donc flou pour l'instant. Peut-être que ce n'est pas la bonne voie à prendre. Quelques personnes pour aider à remettre un peu d'ordre? Merci. A++ Nicolas PS : Promis, il n'y aura pas de discussion stérile... (Raph... Martin...)
