Re: backport Imagemagick
Le Fri, Oct 26, 2001 at 10:38:21AM +0200, georges mariano écrivait: Je voudrais qu'on m'explique pourquoi le doit ?? Exemple, Le passage de samba2.0 a samba4.0, (pas de panique, c'est un exemple virtuel ;-) Si ça compile parfaitement avec la libc6 2.1, pourquoi le faire obligatoirement avec la 2.2 ?? Parce que le monde n'est pas aussi simple que tu veux bien le croire. C'est indispensable si le soname de la bibliothèque change et que le paquet dépendant est différent (exemple les != libgal). C'est le seul moyen de se débarasser des dépendances sur des anciens paquets. Je vois vraiment pas l'intérêt en terme de stabilité (ça va obliger à mettre à jour plus de paquet que nécessaire donc plus de risques !) Unstable est fait(e) pour *changer*. On n'a pas le genre de considérations que tu évoques. un apt-get source -b qui foire parce qu'il demande les dernières libs __à la mode__ alors que derrière un debian/rules binary fonctionne (très) bien ... Personne ne t'en voudra d'éditer les Build-Depends voire d'utiliser l'option -d dans dpkg-buildpackage (que tu peux passer à debuild également si tu l'utilises). En attendant, spécifier des versions dans les Build-Depends c'est le seul moyen qu'on a de s'assurer que les paquets seront recompilés avec les bonnes versions sur les autobuilders. Tout ce que je demande c'est que les paquets pour lesquels il n'est pas __nécessaire__ de frimer ne nous __obligent__ pas à upgrader la moitié du système ... Tu n'as besoin de rien upgrader pour essayer de compiler ... (merci de prendre en considération les __ __ qui sont pas là pour rien) Merci de ne pas penser qu'à toi. Ceux qui disent que woody me semblent croire que 90% des paquets nécessitent le passage en woody, ben je suis désolé, mon backport du monde démontre (statistiquement) le contraire... Donc la situation n'est pas si dramatique que cela ... En vrac, ') l'exemple fort-a-propos de /usr/share/doc, pourquoi tant de soucis pour la compatibilité descendante de fichiers de docs et, apparemment bcp moins de réflexion sur un truc comme perl ?? Je vais te dire un truc, tu m'énerves. Qu'est-ce qui te fait dire que la transition pour perl a été mal gérée ? Au contraire, tout est *très* propre. Pas forcément compatible avec le monde du perl avant 5.6 mais bien plus clean pour l'avenir et les prochaines mises à jour. '') je ne me souviens pas que la moitié des applis upstream linux induisent une mise à jour radicale dans leurs dernières versions suite à des modifs perl amont. J'en déduis que le problème de transition perl est __spécifique__ Debian, et là, ça me mets très mal à l'aise... Est-ce que tu peux détailler ce qui ne va pas ? J'ai l'impression que tu racontes un peu n'importe quoi à tort et à travers. ''') pourquoi est-il si inconcevable de modifier le paquet xlib6g(-dev) actuellement dans potato, de lui rajouter les deux Parce que potato ne prend plus de modifs autres que celles de sécurité. lignes, et régler ainsi pour une foultitude de paquets le problème de la recompilation ?? ça m'a pris 5mn chez moi (plutôt 15)... Je te propose de lancer un projet recompilation des paquets récents sur stable et de mettre à disposition tes paquets modifiés pour simplifier la vie de ceux qui veulent faire comme toi ... En attendant, ce n'est pas un objectif primordial pour Debian. A+ -- Raphaël Hertzog -+- http://strasbourg.linuxfr.org/~raphael/ Le bouche à oreille du Net : http://www.beetell.com Naviguer sans se fatiguer à chercher : http://www.deenoo.com Formation Linux et logiciel libre : http://www.logidee.com
Re: backport Imagemagick
Le Fri, Oct 26, 2001 at 03:50:52PM +0200, georges mariano écrivait: Pourquoi devrais-je avoir un but (sous-entendu dans la ligne Debian) ? Mon seul objectif, c'est d'avoir un système qui réponde à mes besoins. Ce que tu dis là, nous prouves soit que tu es un parasite (qui veut profiter sans rien rendre à Debian) soit que tu es un trolleur terrible qui lance des discussions enflammées sans espoir quelconque de faire changer quoi que cela soit. Mais quand on me répond que le système Debian est l'un des plus stable quitte à réinstaller la moitié de l'environnement des utilisateurs actuels pour une histoire de Debian Policy, je m'interroge. Tu as du mal à assimiler un concept de base... tu ne respecte pas les critères d'utilisation standard de Debian, et bien tu assumes. Personnellement, je me sens productif ici, en backportant ce dont nous avons besoins, je nous évite (enfin je crois) pas mal de problèmes de ... stabilité (cf la liste user). C'est toute mon ambition, même si elle passe par une technique que certains prennent pour impossible... Il ne reste plus qu'à partager ton travail avec un peu plus de monde... Ben si mes diagnostics sont étiquetés comme n'importe quoi, c'est plutôt foutu d'avance non ??? Oui, il faudrait : - éviter les lignes pleines de point d'interrogation - comprendre le pourquoi de tes difficultés et reconnaître qu'il y a d'autres objectifs importants dans Debian que le backport - partager le fruit de ton travail (pas juste avec des mails assez mal formatés dans les listes Debian somme toute assez confidentielles) A+ -- Raphaël Hertzog -+- http://strasbourg.linuxfr.org/~raphael/ Le bouche à oreille du Net : http://www.beetell.com Naviguer sans se fatiguer à chercher : http://www.deenoo.com Formation Linux et logiciel libre : http://www.logidee.com
Re: backport Imagemagick
On Sat, Oct 27, 2001 at 05:15:17PM +0200, georges mariano wrote: On Sat, 27 Oct 2001 16:12:13 +0200 [EMAIL PROTECTED] (Denis Barbier) wrote: DB DB Très bien, continue de recompiler sans te poser de questions, bon courage. sans me poser de questions, t'es gonflé de dire ça... Cette réponse avait été envoyée en privé suite à un message que tu m'as envoyé en privé. ça tombe bien, moi aussi je voulais abréger ... voici où j'en suis a) en 15mn, j'ai mon paquet woody de snmpkit-0.8, aucune difficulté à signaler... mais bon, je compile que pour ma machine ;-) [après faut une heure pour tout bien faire dans les coins ;-)] b) j'ai cassé ce paquet en 5mn !! j'ai juste fait intervenir la commande que tu me suggérais mais en utilisant les paquets debian évidemment (je vais pas tout réinstaller en tarball!!) donc avec autoconf/automake Debian, la commande que tu suggère (+ un ptit coup de libtoolize, y'avait un problème de version (!?)) ben maintenant ça compile plus... Non, je t'avais suggéré de faire cette commande avec les sources upstream, je résume - en touchant le moins possible les sources upstream, j'obtiens sans difficulté le paquet Debian - en faisant intervenir les outils autmake/autoconf Debian, ça casse tout... Avec ça, en déduire que le problème est upstream et que le mainteneur fait du bon boulot... ben moi j'y arrive pas... C'est pourtant très simple, il suffit de faire ce que je t'avais suggéré dans le mail précédent ; tu prends les sources, autoconf 2.13 et automake 1.4-p5, tout ça upstream, donc sans un poil Debian, tu fais aclocal autoheader automake -a autoconf ./configure make Si tu fais une installation from scratch, il faut aussi installer libtool, ou copier /usr/share/aclocal/libtool.m4 dans /usr/local/share/aclocal/libtool.m4 Et tu verras que ça plante, alors que tu n'as tapé aucune commande packagée par ces abrutis de Debian. À partir de là, le scénario que j'avais proposé dans le mail précédent te semblera peut-être plausible. Enfin bon, on peut toujours rêver. Denis
Re: backport Imagemagick
Raphael Hertzog wrote: Le Thu, Oct 25, 2001 at 10:03:51PM +0200, georges mariano écrivait: ben je reprendrai une suggestion faite ici (et pour laquelle je suis d'accord à 100%), un développeur devrait bosser sous potato sauf exigences spécifiques... Et là je suis 100% contre, en faisant cela, on ne passe jamais aux nouvelles versions des bibliothèques, et on ne bouge pas. Bon, comme c'est moi qui est fait la suggestion, je suis obligé de répondre :) Il ne s'agit pas d'être à 100% pour ou contre. Même moi, je dois pas être pour à plus de 80% :) Plus sérieusement, en réponse à ce que Raphaël a dit, mon point de vue est le suivant : 1. Oui, il faut que les paquets puissent recompiler sous stable 2. Oui, il faut que les paquets utilisent les nouvelles bibliothèques, disponibles uniquement en unstable Et je crois que dans de nombreux cas, c'est possible, si on (les mainteneurs) fait l'effort : 1. De compiler son nouveau paquet sous stable 2. Une fois que ça marche, de passer à unstable et de le compiler sous unstable, et d'uploader cette version 3. Si pour faire 2, on doit faire des changements, il faut faire en sorte que ça soit compatible avec 1. 4. Comme tout le monde fait ça (rires), on peut facilement recompiler aussi les nouvelles libs dont on a besoin sous stable, donc faire 1. avec les nouvelles libs. Ça veut dire, pour les mainteneurs, bosser en stable et backporter le monde dès qu'on a un paquet qui est un peu trop dépendant ... Je sais, ça parait fou et c'est totalement impossible quand, par exemple, la version de perl change (c'est ce que j'ai appelé dans un mail précédent un gros changement du système). Mais c'est quand même faisable sur certains paquets. Par exemple avec un miroir officiel paquets de debian-devel pour stable. Je suis pourtant d'accord avec toi (Raphaël) quand tu dis : les problèmes de recompilation, tu peux difficilement les éviter [...] quand on a de si grands écarts (temporels et fonctionnels) entre deux versions Le cas de Perl est flagrant. Mais j'ai l'impression (et je pense que c'est cette même impression qui met GM de mauvais poil ;-)) que certains mainteneurs ne font pas l'effort d'essayer de se poser la questions de savoir si peut-être y'a une chance pour qu'en y réfléchissant un peu ... le paquet puisse compiler sous potato. Si 1 mainteneur travaille en potato, il va se faire ch... pour rien. Ça ne peut pas marcher. Mais si tous les mainteneurs essayent de travailler en stable et de backporter ce dont ils ont besoin, alors : 1. on pourrait avoir des stable étendues plus facilement 2. peut-être (je n'en suis pas sur parce que le problème me semble orthogonal) qu'on pourrait avoir des versions stable plus fréquentes. Maintenant, je suis aussi conscient des difficultés que peuvent avoir les mainteneurs qui bossent sur des paquets modernes. Mais dans l'ensemble, on arrive à avoir pas mal de paquets recompilés pour potato (kernel2.4, kde, xfree4, etc), alors pourquoi ne pas rêver un peu. Et puis si on ne parle pas de ça sur -devel-french, où va-t-on en parler ? :) Nico. -- Nicolas SABOURET LIMSI-CNRS, BP133, 91403 Orsay, France http://www.limsi.fr/Individu/nico
Re: backport Imagemagick
Bon un dernier pour la route... RH d'accord à 100%), un développeur devrait bosser sous potato sauf RH exigences spécifiques... RH RH Et là je suis 100% contre, en faisant cela, on ne passe jamais aux RH nouvelles versions des bibliothèques, et on ne bouge pas. RH RH Un développeur doit compiler sur unstable. Alors faut faire de la pub basée sur l'unstabilité de Debian :) Je voudrais qu'on m'explique pourquoi le doit ?? Exemple, Le passage de samba2.0 a samba4.0, (pas de panique, c'est un exemple virtuel ;-) Si ça compile parfaitement avec la libc6 2.1, pourquoi le faire obligatoirement avec la 2.2 ?? Je vois vraiment pas l'intérêt en terme de stabilité (ça va obliger à mettre à jour plus de paquet que nécessaire donc plus de risques !) [imagemagick _exige_ libdps alors que c'est pas _nécessaire_ ...] Ce qui me mets vraiment de mauvais poil c'est un apt-get source -b qui foire parce qu'il demande les dernières libs __à la mode__ alors que derrière un debian/rules binary fonctionne (très) bien ... Tout ce que je demande c'est que les paquets pour lesquels il n'est pas __nécessaire__ de frimer ne nous __obligent__ pas à upgrader la moitié du système ... (merci de prendre en considération les __ __ qui sont pas là pour rien) Ceux qui disent que woody me semblent croire que 90% des paquets nécessitent le passage en woody, ben je suis désolé, mon backport du monde démontre (statistiquement) le contraire... En vrac, ') l'exemple fort-a-propos de /usr/share/doc, pourquoi tant de soucis pour la compatibilité descendante de fichiers de docs et, apparemment bcp moins de réflexion sur un truc comme perl ?? '') je ne me souviens pas que la moitié des applis upstream linux induisent une mise à jour radicale dans leurs dernières versions suite à des modifs perl amont. J'en déduis que le problème de transition perl est __spécifique__ Debian, et là, ça me mets très mal à l'aise... ''') pourquoi est-il si inconcevable de modifier le paquet xlib6g(-dev) actuellement dans potato, de lui rajouter les deux lignes, et régler ainsi pour une foultitude de paquets le problème de la recompilation ?? ça m'a pris 5mn chez moi (plutôt 15)... Mais si j'ai bien compris c'est une hérésie chez Debian cause que potato est dans le marbre ... J'arrète là, la liste est longue des spécificités packaging Debian qui m'échappent. Je conçois parfaitement que la politique Debian s'affine/évolue entre deux releases, mais à partir du moment ou cette même politique m'oblige à gérer mon parc à-la-windows en courant après la dernière version de tel ou tel paquet ... tout ça pour pouvoir installer la dernière version d'un logiciel qui n'a rien voir avec ces décisions je me demande où est le gain ... 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: backport Imagemagick
On Fri, 26 Oct 2001, georges mariano wrote: Mon objectif est de faire fonctionner bientôt dix machines en permanence en expliquant aux utilisateurs pourquoi il est si difficile de mettre sur les machines debian/potato telle ou telle applis (dans sa dernière version) dont dipose sans problème le premier mandrakien venu ... Parce que tu crois que ca ne casse rien dans sa Mandrake ? -- Jean-Christophe Dubacq -- ATER en informatique à la faculté d'Orsay. Tel: 01 69 15 76 43 / 06 64 86 10 56 --- Email: [EMAIL PROTECTED]
Re: backport Imagemagick
On Fri, Oct 26, 2001 at 12:12:34PM +0200, georges mariano wrote: On Fri, 26 Oct 2001 11:25:09 +0200 Roland Mas [EMAIL PROTECTED] wrote: RMLa possibilité d'upgrader un système. Si l'état initial est connu RM (la stable précédente ou celle d'avant), on peut. S'il est inconnu RM parce que le mec s'est installé des paquets rétroportés à différents RM moments, on peut pas upgrader de manière déterministe (ou alors, il RM faut prendre en compte toutes les combinaisons possibles d'upgrades RM intermédiaires). Le principe fondamental des OS modernes c'est de garder autant que possible une independance entre les couches existantes. En matiere de (re)compilation de softs ceci est assuré par les mécanismes (sophistiqués) d'éditions de liens, de chargement dynamique etc ... On peut envisager d'avoir plusieurs version d'une même librairies et jouer ensuite sur les réglages possible. Moralité : Ce premier paragraph (celui de RM!) est orthogonal à une bonne perception de ce quoi doit faire un OS moderne comme Linux/Debian... [...] Dans le genre « je dis n'importe quoi », je te ferai remarquer que pour l'instant c'est toi le vainqueur, ton diagnostic sur les problèmes rencontrés avec imagemagick était complètement délirant. Est-ce que tu comptes l'admettre un jour, ou tu vas me démontrer que c'est en fait moi qui me suis trompé ? Sur le fond, ce n'est pas la peine de répondre, puisqu'apparemment tu as ta propre définition de ce qu'est la stabilité de Debian, et ceux qui n'ont pas la même ne sont que des abrutis. Oui, il y a des problèmes, certains développeurs font du travail de merde, certaines décisions techniques visent à favoriser la vie des autobuilders en se foutant des implications sur les utilisateurs, mais si ton but est que ça change, il faudrait essayer d'être productif et proposer des idées pour qu'elles soient relayées. Denis
Re: backport Imagemagick
On Fri, 26 Oct 2001 14:36:19 +0200 [EMAIL PROTECTED] (Denis Barbier) wrote: DB On Fri, Oct 26, 2001 at 12:12:34PM +0200, georges mariano wrote: DB Dans le genre « je dis n'importe quoi », DB Oui, il y a des problèmes, Faudrait savoir... DB certains développeurs font du travail de merde, pas celui de ImageMagick donc... DB certaines décisions techniques visent à favoriser la vie des autobuilders pas celles qui tournent autour d'autoconf ou des différents organisations de perl donc... DB en se foutant des implications sur les utilisateurs, J'ai pas de bol, je tombe toutjours sur de mauvais exemples de vrais problèmes ... comment voulez-vous être crédible après ça... DB mais si ton but est que ça change, Pourquoi devrais-je avoir un but (sous-entendu dans la ligne Debian) ? Mon seul objectif, c'est d'avoir un système qui réponde à mes besoins. Mais quand on me répond que le système Debian est l'un des plus stable quitte à réinstaller la moitié de l'environnement des utilisateurs actuels pour une histoire de Debian Policy, je m'interroge. DB il faudrait essayer d'être productif et proposer des idées Personnellement, je me sens productif ici, en backportant ce dont nous avons besoins, je nous évite (enfin je crois) pas mal de problèmes de ... stabilité (cf la liste user). C'est toute mon ambition, même si elle passe par une technique que certains prennent pour impossible... DB pour qu'elles soient relayées. Ben si mes diagnostics sont étiquetés comme n'importe quoi, c'est plutôt foutu d'avance non ??? 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: backport Imagemagick
georges mariano [EMAIL PROTECTED] writes: NS Parait qu'il y a une équipe assurance qualité chez Debian ?? NS NS Je ne pense pas que qa soit en cause. C'est plutôt tous les mainteneurs NS (nous) qui recompilons nos paquets sous Woody, créant ainsi des NS dépendances trop fortes. arggg c'est marrant la dernière fois que j'ai dis ça (quasi mot pour mot) je me suis fais incendier ...(j'exagère juste un peu...) Les paquets destinés à testing/unstable ne sont pas fait pour être backportés. Nous avons déjà assez de travail avec unstable. Si on devait mettre les versions de dépendance à la main, et compiler avec des vieilles versions de bibliothèques, on en serait encore à la libc5 et consort. Bon ceci dit, je voulais dire que je me pose la question de savoir pourquoi y'a des paquet qui arrivent dans woody alors qu'ils ne se recompilent pas automatiquement ... (autre exemple ? debconf, il y a quelques temps, plantage cause qu'un fichier po tchèque je crois avait une erreur de syntaxe [évidemment 'rm le-dit-fichier.po' ... euh, y'a un rapport avec perl ?] le plus marrant c'est le nom du mainteneur debconf...) Qu'est ce que tu racontes ? i.e suffit pas de balancer les initiales Q.A sur un site web pour s'approprier le sens véritable de ces initiales... autant pas les mettre. Il faudrait déjà que tu lises ce qu'il y a d'écrit sur le site web avant balancer des inepties. NS Qui essaye de calmer GM :) euh, t'as rien de mieux à faire ?? (de plus constructif surtout ;-) :) Il essaie de répondre à tes questions, estime-toi heureux. Essaie au moins pour une fois de respecter les gens qui tentent de t'aider. -- Jérôme Marant [EMAIL PROTECTED] [EMAIL PROTECTED] http://marant.org
Re: backport Imagemagick
georges mariano wrote: On Wed, 24 Oct 2001 17:53:39 +0200 Nicolas SABOURET [EMAIL PROTECTED] wrote: NS N'importe quoi. NS Bah non. C'est normal parce que tout perl a changé ! Les changements de perl ont donc un lien avec : - la valeur vendor qui produit une cible Makefile qui n'existe pas ? (la valeur site passe ... elle) Oui. - ce genre d'erreur également (je garantis pas les retours à la ligne...) ?? dh_movefiles: debian/imagemagick//usr/share/man/man3/Image::Magick.3pm not found Je pense que oui. NS Bah ... de Woody ? Je comprends pas ta question. On peut compiler un NS paquet sous Woody aussi :) Perdu ... je sais _aussi_ recompiler sur woody (trop fort!!!) L'erreur obtenue est la première de la liste donnée [...] Je n'avais vraiment pas compris ta question (le de Woody, c'était pour rire, et pour montrer que je n'avais pas compris). Je sais bien que tu n'es pas un newbie. Je pense que personne ici n'a cette impression !! Tu demandais : D'où viennent les paquets binaires ?. Je n'avais pas compris de quels paquets il s'agissait. Maintenant, ce que j'ai compris, c'est que tu as aussi essayé de recompiler le truc sous Woody, et que tu as qd même des erreurs. C'est ça ? Juste pour me convaincre/calmer : quelqu'un peut-il faire un apt-get source -b imagemagick ?? ... sur une woody évidemment !! C'est ça que je n'avais pas compris. Au départ, tu étais sur Potato et j'ai du louper le passage ou tu arrêtait de backporter le monde :) echo Backport the world :) [évidemment 'rm le-dit-fichier.po' ... euh, y'a un rapport avec perl ?] le plus marrant c'est le nom du mainteneur debconf...) Accorde au moins le droit à l'erreur aux mainteneurs... C'est vrai que celle-là est pas mal, mais un paquet testing n'est pas obligatoirement parfait ... euh, t'as rien de mieux à faire ?? (de plus constructif surtout ;-) Je trouvais juste que la critique sur l'impossibilité de recompiler les paquets est fondée. L'exemple (utilisant perl) était mauvais, mais je crois que c'est un problème général et puisqu'on est sur devel, on devrait pouvoir en parler. Nico. -- Nicolas SABOURET LIMSI-CNRS, BP133, 91403 Orsay, France http://www.limsi.fr/Individu/nico
Re: backport Imagemagick
On Wed, 24 Oct 2001 22:04:55 +0200 [EMAIL PROTECTED] (Denis Barbier) wrote: D DB Au lieu de t'énerver, tu aurais pu regarder si c'est un bug connu. DB direction http://bugs.debian.org/imagemagick et là, ô miracle, qu'est-ce DB qu'on voit ? Tout à fait d'accord avec toi, malheureusement j'étais en déplacement aujourd'hui... Bon, tu l'as fait pour moi ... ;-) DB Seulement le responsable du paquet n'arrive pas à reproduire ce bug, ben je reprendrai une suggestion faite ici (et pour laquelle je suis d'accord à 100%), un développeur devrait bosser sous potato sauf exigences spécifiques... 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: backport Imagemagick
Le Thu, Oct 25, 2001 at 10:03:51PM +0200, georges mariano écrivait: ben je reprendrai une suggestion faite ici (et pour laquelle je suis d'accord à 100%), un développeur devrait bosser sous potato sauf exigences spécifiques... Et là je suis 100% contre, en faisant cela, on ne passe jamais aux nouvelles versions des bibliothèques, et on ne bouge pas. Un développeur doit compiler sur unstable. Et même testing c'est limite dans certains cas. Ce ne veut pas dire qu'il doit faire exprès d'emmerder les utilisateurs qui veulent recompiler sur potato ... :-) les problèmes de recompilation, tu peux difficilement les éviter ... surtout quand on a de si grands écarts (temporels et fonctionnels) entre deux versions successives de Debian. A+ -- Raphaël Hertzog -+- http://strasbourg.linuxfr.org/~raphael/ Le bouche à oreille du Net : http://www.beetell.com Naviguer sans se fatiguer à chercher : http://www.deenoo.com Formation Linux et logiciel libre : http://www.logidee.com
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
