Re: Uploader dans stable (was: Re: knoppix ( limite hs !!! ))
En réponse à Erwan David [EMAIL PROTECTED]: ben en fait c'est l'ensemble du processus de debianisation des emacs qui est, à mon avis, à revoir. désolé, si j'ai bien compris, ce genre de réflexion c'est /dev/null (tu n'entre dans aucune des catégories prévues par la policy locale...) bon dimanche. A+ -- mailto:[EMAIL PROTECTED]
Re: Uploader dans stable (was: Re: knoppix ( limite hs !!! ))
On Fri, Jun 27, 2003 at 11:22:10PM +0200, Georges Mariano wrote: oui, je sais lui il gère son paquet, moi mon installation, et c'est lui qui a la vue d'ensemble... de quelle vue tu parles ? Celle du développement de la prochaine version, sans doute... Upstream demande la libc2.2, debian également. Tout le monde est d'accord Upstream demande 2.2 or newer, donc Debian a juste. Après tout y'a un truc que je pige pas : pourquoi upstream n'aurait pas une bonne raison de demander la 2.1 et pas la 2.2 ? Ca a peut-être une importance dans certains cas, c'est sans doute pourquoi on se retrouve avec des libpng[123]. Dans le cas de libc, c'est compatible ascendant et par conséquent pas un problème (pour que ça marche avec 2.1 et pas 2.2, il faut le faire exprès). upstream a toujours raison mais doit s'effacer devant debian ?? c'est bien ça? Il n'y pas d'incompatibilité entre les deux positions dans ce cas /Y -- Marbles should be kept together.
Re: Uploader dans stable (was: Re: knoppix ( limite hs !!! ))
Le Sun 29/06/2003, Georges Mariano disait En réponse à Erwan David [EMAIL PROTECTED]: ben en fait c'est l'ensemble du processus de debianisation des emacs qui est, à mon avis, à revoir. désolé, si j'ai bien compris, ce genre de réflexion c'est /dev/null (tu n'entre dans aucune des catégories prévues par la policy locale...) ben si on regarde le bug 125708 (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=125708archive=yes) on comprend pourquoi j'ai renoncé complètement à xemacs debianisé... -- Erwan
Re: Uploader dans stable (was: Re: knoppix ( limite hs !!! ))
On Sun, Jun 29, 2003 at 10:51:26PM +0100, Yves Rutschle wrote: On Fri, Jun 27, 2003 at 11:22:10PM +0200, Georges Mariano wrote: oui, je sais lui il gère son paquet, moi mon installation, et c'est lui qui a la vue d'ensemble... de quelle vue tu parles ? Celle du développement de la prochaine version, sans doute... Et celle de l'interaction avec les autres packages ainsi que celle des problemes liees aux autres architectures. Sans compter les bug report precedents, donc l'historique du package. Sur, tous les DD ne fournissent pas un travail de qualite egale, certains feront de tres bon paquets, d'autres de moins bon paquets, mais en general, les paquets (une fois release) sont plutot de bonne qualite. BTW, au passage, a propos de perl, vous avez tous evidement lu : mail de Adam Heath sur debian-devel On Sat, 28 Jun 2003, Mark Hedges wrote: I apologize for filing multiple bug reports about this before seeking consensus on the list. Is someone going to put perlapi-5.6.1 back into sarge? Lots of packages indirectly depend on this and cannot be installed now. Should there be a dummy package for compatibility with perl 5.8.0? No. The packages that require perl 5.6.1 need to be updated. They have had plenty of time to do so. Because they hadn't, they had been holding up perl 5.8 from entering testing, which was keeping lots of other packages in the dep tree from progressing. Amicalement, Sven Luther
Re: Uploader dans stable (was: Re: knoppix ( limite hs !!! ))
Le 25.06.03, Denis Barbier a tapoté : | On Wed, Jun 25, 2003 at 11:24:44AM +0200, Thomas Nemeth wrote: | [...] | | Cependant, maintenant que libpng10 et libpng12 ont des soname correcte, | | ils peuvent etre installe simultanement, et le probleme n'est plus aussi | | Mais moi je ne veux pas qu'ils soient installés simultanément. | Avoir 2 fois la même chose (ou 2 trucs qui font la même chose) | n'est pas fait pour m'enchanter (en l'occurence 4 fois, pour | l'instant)... | | C'est marrant, il y en a qui râlent pour garder l'ancienne version, d'autres | pour ne garder que la nouvelle, d'autres qui veulent tout, et d'autres qui | râlent pour le plaisir. Ça va être difficile de contenter tout le monde. Tu vas m'expliquer en quoi il est anormal de ne vouloir qu'une seule version d'une bibliothèque. Avoir 2 fois la même chose sur sa machine, peu de monde le souhaite. Si certains veulent tout avoir, c'est leur problème : le système de paquetage est justement là pour ça et ça, il le fait bien. Mais de là a avoir plusieurs choses en double, triple, quadruple voire plus, il y a un monde. Est-ce si compliqué de faire des paquets qui ne dépendent que d'une seule version d'une bibliothèque (et si possible tous de la même) ? Thomas -- printk(KERN_WARNING Multi-volume CD somehow got mounted.\n); 2.2.16 /usr/src/linux/fs/isofs/inode.c
Re: Uploader dans stable (was: Re: knoppix ( limite hs !!! ))
On Fri, Jun 27, 2003 at 11:22:10PM +0200, Georges Mariano wrote: En réponse à Sven Luther [EMAIL PROTECTED]: et aussi accepter que le mainteneur ai peut-etre une vue d'ensemble que tu n'a pas. oui, je sais lui il gère son paquet, moi mon installation, et c'est lui qui a la vue d'ensemble... de quelle vue tu parles ? gettext (0.10.38-3) unstable; urgency=medium * Added libc6.1-dev (= 2.2) to Build-Depends for alpha and ia64. Thanks to Matt Taggart for the report. :-) Ben j'aimerai bien t'entendre demander au mainteneur de faire le même effort pour convaincre upstream de bien vouloir prendre en considération ce point _également_, tout comme tu demande systématiquement de faire preuve de bonne volonté à l'égard du DD. Alors la, je vois pas pourquoi moi je devrait aller demander des choses que tu desire au DD qui ensuite devrait aller le demander a upstream ? Si upstream a un probleme, pourquoi ne lui en parle tu pas directement ? De plus, qui a part debian supporte alpha ? La référence pour une appli, c'est l'upstream. Dès lors, je préférerai que ce soit upstream qui décide de mettre la barre à la 2.2 et pas un intermédiaire entre moi (utilisateur) et lui. Oui, comme dans l'exemple de xfree86, ou upstream ne tourne meme pas sur la moitie des architectures que debian supporte. Upstream demande la libc2.2, debian également. Tout le monde est d'accord C'est pas plus compliqué que ça. Après tout y'a un truc que je pige pas : pourquoi upstream n'aurait pas une bonne raison de demander la 2.1 et pas la 2.2 ? (a-t-il l'intention à l'avenir de se préoccuper de alpha et ia64 ?? si oui, qu'il le «dise» lui-même) Pourquoi upstream ne se serait-il pas trompe ? Le plus probable c'est qu'il n'a pas tester en alpha ou ia64, ou qu'il n'a pas rencontre ces problemes. upstream a toujours raison mais doit s'effacer devant debian ?? c'est bien ça? Non, c'est du logiciel libre, si ce que upstream ou debian fait ne te plait pas, libre a toi de forker dans ton coin. PS : de la même manière, _par principe_ (policy?) un DD devrait configurer une appli comme upstream la livre par défaut [sauf les répertoires standard] N'importe quoi, si upstream fait n'importe quoi, et cela arrive souvent, alors il faut modifier la config, c'est aussi simple que cela, il y a que les tetes de mules qui ne veulent pas le comprendre. (je viens de passer aujourd'hui sur un paquet qui active mysql et désactive postgres ... Debian a-t-il choisi de supporter uniquement mysql ??) Si cela ne te convient pas, fait un bug wishlist et cela sera ou justifie ou corrige. (déjà vue avec désactivation de kde et activation de gnome...) mais là encore, c'est certainement un manque de bol et d'objectivité de ma part... je sais. Et un refus de faire le rapport de bug et d'entrer en communication avec le packageur. Amicalement, Sven Luther
Re: Uploader dans stable (was: Re: knoppix ( limite hs !!! ))
Le Fri 27/06/2003, Frédéric Bothamy disait Dans ce cas, tu peux peut-être aller voir ce message http://lists.debian.org/debian-emacsen/2003/debian-emacsen-200305/msg0.html qui tente de séparer les fonctionnalités de XEmacs en différents paquets, mais je n'ai pas l'impression que l'idée de Daniel Schepler est été très bien accueillie ... ben en fait c'est l'ensemble du processus de debianisation des emacs qui est, à mon avis, à revoir. -- Erwan
Re: Uploader dans stable (was: Re: knoppix ( limite hs !!! ))
On Thu, Jun 26, 2003 at 02:59:35PM +0200, Georges Mariano wrote: En réponse à Sven Luther [EMAIL PROTECTED]: soname majeur change, et les dependances faite par le mainteneur du package sont soit justifie, soit des bugs qu'il faut soumettre. Il va de soit qu'il faut aussi pouvoir accepter la reponse du mainteneur dans ce cas, apres tout il a peut etre raison et vous tort finalement. J'aime bien ce paragraphe... il est exprime toute la ... clarté de ta position :-) Tu avais bien dis upstream a toujours raison ?? Tout ce que je voulais dire, c'est que lors de la discussion avec le mainteneur lors d'un bug report tu soit objectif, et essaye de comprendre les arguments qu'il te donnera, et pas t'enfermer dans le j'ai raison, tous les autres ont tort dont tu a l'habitude. S'aliener le mainteneur d'un package n'est pas une cool idee lorsque tu essaye d'obtenir des modifications du package en question, et il te faut de la diplomatie, et aussi accepter que le mainteneur ai peut-etre une vue d'ensemble que tu n'a pas. Par hasard, je compile gettext là... si on regarde bien le configure, il teste par rapport a la libc ___2.1___ «checking whether we are using the GNU C Library 2.1 or newer... yes» Si je veux installer sur ma machine, le paquet Debian me dit non, il vous faut la libc ___2.3___, (deux versions de plus!!) Normal, car la libc 2.3 est celle qui est actuellement dans sid. Elle est backward compatible avec les binaires compile avec des plus anciennes versions de la libc, mais le contraire n'est pas vrai. real3m9.786s user2m2.610s sys 0m55.720s ça c'est le temps qu'il faut pour backporter gettext, dans un chroot avec la libc ___2.2___ Sur, sur, multiplie cela par 11, certaines arch etant bien plus lente que la machine que tu utilise (dont tu ne dis rien d'ailleurs), sans compter qu'il faut que tu modifie tous les autobuilders pour aller compiler avec des bouts de woody et des bouts de sid. c'est très compliqué, faut juste faire qqchose comme : time fakeroot apt-get source -b gettext (NB : source pris dans sid) Oui, sur, mais la c'est un cas facile, qui ne pose pas vraiment probleme. Mais tu choisi deliberement d'ignorer les cas plus difficile, et c'est pour cla que ton raisonement ne tient pas. Tu nous explique ? Deux versions de plus exigée ?? C'est pas deux versions de plus exige, les packages sont compiler sur une sid, pour la future version sarge, qui aura la version 2.3 de la libc, donc c'est exactement la version qu'il faut qui sera utilise, n'en deplaise a ceux qui souhaiterai reutiliser ces packages dans une woody, voir une potato, tel quel. Pour que le mainteneur Debian ai finalement raison de demander la 2.3, il faut qu'upstream ai tort de demander seulement 2.1... De quel côté tu veux avoir raison/tort ?? Non, tu remarquera que la dependance upstream est une dependance source, alors que la dependance debian est une dependance binaire, et la glibc 2.3 est backward compatible avec des binaires compile avec une plus ancienne glibc, mais pas vice-versa. PS : je demande même pas la 2.1(potato?), juste la 2.2(woody)... Oui, oui, sur, mais sans t'attarder sur les raison de cela, je suis sur que si tu prenait la peine de reflechir un peu sans prejuge, tu verrai pourquoi il doit en etre comme cela. A nouveau, rien ne t'empeche de faire des backports comme tu le fait deja, c'est pourquoi les build-depends ne sont pas sur libc6.1-dev (= 2.2), et non libc6.1-dev (= 2.3). Mmm, je me demande pourquoi ils ne sont pas de libc6.1-dev (= 2.1), mais le mainteneur a surement une bonne raison ... Oui, dans le changelog on peut lire : gettext (0.10.38-3) unstable; urgency=medium * Added libc6.1-dev (= 2.2) to Build-Depends for alpha and ia64. Thanks to Matt Taggart for the report. ... -- Santiago Vila [EMAIL PROTECTED] Fri, 13 Jul 2001 08:07:16 +0200 Amicalement, Sven Luther A+ -- mailto:[EMAIL PROTECTED] -- Pensez à lire la FAQ de la liste avant de poser une question : http://savannah.nongnu.org/download/debfr-faq/html/ To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Uploader dans stable (was: Re: knoppix ( limite hs !!! ))
En réponse à Sven Luther [EMAIL PROTECTED]: et aussi accepter que le mainteneur ai peut-etre une vue d'ensemble que tu n'a pas. oui, je sais lui il gère son paquet, moi mon installation, et c'est lui qui a la vue d'ensemble... de quelle vue tu parles ? gettext (0.10.38-3) unstable; urgency=medium * Added libc6.1-dev (= 2.2) to Build-Depends for alpha and ia64. Thanks to Matt Taggart for the report. :-) Ben j'aimerai bien t'entendre demander au mainteneur de faire le même effort pour convaincre upstream de bien vouloir prendre en considération ce point _également_, tout comme tu demande systématiquement de faire preuve de bonne volonté à l'égard du DD. La référence pour une appli, c'est l'upstream. Dès lors, je préférerai que ce soit upstream qui décide de mettre la barre à la 2.2 et pas un intermédiaire entre moi (utilisateur) et lui. Upstream demande la libc2.2, debian également. Tout le monde est d'accord C'est pas plus compliqué que ça. Après tout y'a un truc que je pige pas : pourquoi upstream n'aurait pas une bonne raison de demander la 2.1 et pas la 2.2 ? (a-t-il l'intention à l'avenir de se préoccuper de alpha et ia64 ?? si oui, qu'il le «dise» lui-même) upstream a toujours raison mais doit s'effacer devant debian ?? c'est bien ça? PS : de la même manière, _par principe_ (policy?) un DD devrait configurer une appli comme upstream la livre par défaut [sauf les répertoires standard] (je viens de passer aujourd'hui sur un paquet qui active mysql et désactive postgres ... Debian a-t-il choisi de supporter uniquement mysql ??) (déjà vue avec désactivation de kde et activation de gnome...) mais là encore, c'est certainement un manque de bol et d'objectivité de ma part... je sais. A+ -- mailto:[EMAIL PROTECTED]
Re: Uploader dans stable (was: Re: knoppix ( limite hs !!! ))
Le Wed 25/06/2003, Denis Barbier disait C'est marrant, il y en a qui râlent pour garder l'ancienne version, d'autres pour ne garder que la nouvelle, d'autres qui veulent tout, et d'autres qui râlent pour le plaisir. Ça va être difficile de contenter tout le monde. Quand tu vois le nombre de programmes qui dépendent de 2 versions différentes de la lib ong tu te dis qu'il y a un problème... -- Erwan
Re: Uploader dans stable (was: Re: knoppix ( limite hs !!! ))
Le mer 25/06/2003 à 23:40, Denis Barbier a écrit : C'est marrant, il y en a qui râlent pour garder l'ancienne version, d'autres pour ne garder que la nouvelle, d'autres qui veulent tout, et d'autres qui râlent pour le plaisir. Ça va être difficile de contenter tout le monde. Que ceux qui ne souhaitent pas mettre à jour leur distribution ne fassent plus de mises à jour (ou juste avec la source security), Que ceux qui souhaitent conserver une version donnée d'un paquet utilisent un: echo paquet hold | dpkg --set-selections, Que ceux qui souhaitent tout avoir, qu'ils continuent comme d'habitude. Quant aux autres, qu'ils soient redirigés vers /dev/null ;-) -- Raphaël SurcouF Bordet [EMAIL PROTECTED]
Re: Uploader dans stable (was: Re: knoppix ( limite hs !!! ))
* Erwan David [EMAIL PROTECTED] [2003-06-25 14:48] : Le Wed 25/06/2003, Sven Luther disait Aucun idee, mais a nouveau, c'est un probleme specifique a un package, donc mail au mainteneur ou bug report. Il y a 3 versions différentes de kerberos dans debian, des paquets aussi basiques que lprng ou xemacs imposent leur version de kerberos alors que 95% des utilisateurs n'en ont rien à foutre,j n'y connaissent rien et que ce genre de mécanisme mal utilisé conduit à ouvrir des trous de sécurité. J'ai ouvert un bug sur lprng. Pas encore de réponse du mainteneur. Pour xemacs je ne le fais pas car je n'utilise pas le paquet : les emacs debianisé sont vraiment trop différents de l'upstream. Dans ce cas, tu peux peut-être aller voir ce message http://lists.debian.org/debian-emacsen/2003/debian-emacsen-200305/msg0.html qui tente de séparer les fonctionnalités de XEmacs en différents paquets, mais je n'ai pas l'impression que l'idée de Daniel Schepler est été très bien accueillie ... Il ne semble plus y avoir de dépendance sur PostgreSQL (et donc sur Kerberos) (si j'interprète bien le fichier http://people.debian.org/%7Eschepler/xemacs21/Packages.gz). Fred
Re: Uploader dans stable (was: Re: knoppix ( limite hs !!! ))
On Thu, Jun 26, 2003 at 08:33:25PM +0200, Erwan David wrote: Le Wed 25/06/2003, Denis Barbier disait Si tu te donnes la peine de formaliser cela (i.e. fournir des règles dictant comment les paquets sont compilés et quel est ensuite leur cheminement), je ne serai pas étonné que tu retombes sur ce qui existe actuellement. Pour en revenir à ce que je disais : vous dites que eperl 5.6 ne peut pas fonctionner avec perl 5.8. Or il dépend de perl = 5.6.1 Donc avec perl 5.8 la dépendance est satisfaite : donc bug de dépendance ou j'ai pas compris ce que vous vouliez dire ? Dans une unstable : # apt-get install eperl/stable Reading Package Lists... Done Building Dependency Tree... Done Selected version 2.2.14-4 (Debian:3.0r1a/stable) for eperl ... The following packages have unmet dependencies: eperl: Depends: perlapi-5.6.1 E: Broken packages On ne peut donc pas installer cet eperl avec perl 5.8. Si la compatibilité binaire au niveau des libs était assurée (ça arrive parfois, mais rarement ces derniers temps, et ne peut a priori pas être deviné à l'avance), il est probable que les responsables du paquet perl auraient fait en sorte que perl 5.8 Provides: perlapi-5.6.1, et on aurait alors pu installer eperl compilé avec perl 5.6 sur une machine avec perl 5.8. Denis
Re: Uploader dans stable (was: Re: knoppix ( limite hs !!! ))
On Wed, Jun 25, 2003 at 03:46:29PM +0200, Thomas Nemeth wrote: |Le système de gestion des dépendances de Debian est le meilleur |qui soit, mais ce genre de problème devrait pouvoir être règlé |plus simplement... | | Et ils seront regle avant la release de sarge (dans un ans au pire, si | les estimations sont exacte, quoique j'espere qu'on aurra pas besoin de | 6 mois de freeze pour cela, comme l'estimation le pense. Connaissant les cycles de release de la distro depuis plusieurs années, j'ai tendance à croire que même 1 an est une limite basse ;) Err, 1 ans depuis aujourd'hui, ce qui fait 2 ans en tout si je ne me trompe. Amicalement, Sven Luther
Re: Uploader dans stable (was: Re: knoppix ( limite hs !!! ))
On Wed, Jun 25, 2003 at 02:48:46PM +0200, Erwan David wrote: Le Wed 25/06/2003, Sven Luther disait Aucun idee, mais a nouveau, c'est un probleme specifique a un package, donc mail au mainteneur ou bug report. Il y a 3 versions différentes de kerberos dans debian, des paquets aussi basiques que lprng ou xemacs imposent leur version de kerberos alors que 95% des utilisateurs n'en ont rien à foutre,j n'y connaissent rien et que ce genre de mécanisme mal utilisé conduit à ouvrir des trous de sécurité. Oui, je ne sais pas moi meme pourquoi kerberos est utilise, si tu l'apprend un jour, fait le nous savoir. J'ai ouvert un bug sur lprng. Pas encore de réponse du mainteneur. Pour xemacs je ne le fais pas car je n'utilise pas le paquet : les emacs debianisé sont vraiment trop différents de l'upstream. De tout facon, il n'y a que vi de vrai :))) Amicalement, Sven Luther
Re: Uploader dans stable (was: Re: knoppix ( limite hs !!! ))
En réponse à Sven Luther [EMAIL PROTECTED]: Les histoires de dependances sont affreusement complexes, et pleins de subtilites, et les penser les resoudre avec des yakas, c'est pas tres malin. Sûr, sûr, surtout si on applique le bon vieux principe «pourquoi faire simple quand on peut faire compliqué ?». La question est __aussi__ de savoir si ce n'est pas le processus catuel Debian qui rend les choses «affeusement complexes»... Pour avoir une chance d'améliorer un processus faut aussi être prêt à le remettre en cause et à revoir à la baisse ses ambitions. Autre banalité : C'est pas en améliorant la bougie qu'on a découvert l'ampoule. Si tu ne raisonne qu'en terme de bugreport pour faire avancer les choses, ben c'est sans moi (pas une grosse perte, je te rassure...). BTW, Georges, tu pourrait proposer comme sujet de TER l'annee prochaine une analyse des dependances dans debian, avec un peu de recherche des problemes possibles, et de la sauce theorie des graphes pour assaissoner le tout, non ? Cela permettrait de depasser le stade des on-dit et des rumeurs dans ce cadre pour quelque chose d'un peu plus formel, non ? Si je te dis qu'on y a déjà réfléchi, et on a des pistes plutôt sérieuses (pas en B ni OCaml ;-) Mais dans le cas où il en sort quelque chose, faudra que tu me trouve une sérieuse motivation pour restituer ça à une communauté qui regarde de haut (pour rester correct) ceux qui se permettent d'avoir une attitude critique ... Ah oui, un truc qui ferait du rapport de bug massif ... :o) A+ -- mailto:[EMAIL PROTECTED]
Re: Uploader dans stable (was: Re: knoppix ( limite hs !!! ))
En réponse à Sven Luther [EMAIL PROTECTED]: soname majeur change, et les dependances faite par le mainteneur du package sont soit justifie, soit des bugs qu'il faut soumettre. Il va de soit qu'il faut aussi pouvoir accepter la reponse du mainteneur dans ce cas, apres tout il a peut etre raison et vous tort finalement. J'aime bien ce paragraphe... il est exprime toute la ... clarté de ta position :-) Tu avais bien dis upstream a toujours raison ?? Par hasard, je compile gettext là... si on regarde bien le configure, il teste par rapport a la libc ___2.1___ «checking whether we are using the GNU C Library 2.1 or newer... yes» Si je veux installer sur ma machine, le paquet Debian me dit non, il vous faut la libc ___2.3___, (deux versions de plus!!) real3m9.786s user2m2.610s sys 0m55.720s ça c'est le temps qu'il faut pour backporter gettext, dans un chroot avec la libc ___2.2___ c'est très compliqué, faut juste faire qqchose comme : time fakeroot apt-get source -b gettext (NB : source pris dans sid) Tu nous explique ? Deux versions de plus exigée ?? Pour que le mainteneur Debian ai finalement raison de demander la 2.3, il faut qu'upstream ai tort de demander seulement 2.1... De quel côté tu veux avoir raison/tort ?? PS : je demande même pas la 2.1(potato?), juste la 2.2(woody)... A+ -- mailto:[EMAIL PROTECTED]
Re: Uploader dans stable (was: Re: knoppix ( limite hs !!! ))
Le Wed 25/06/2003, Denis Barbier disait Si tu te donnes la peine de formaliser cela (i.e. fournir des règles dictant comment les paquets sont compilés et quel est ensuite leur cheminement), je ne serai pas étonné que tu retombes sur ce qui existe actuellement. Pour en revenir à ce que je disais : vous dites que eperl 5.6 ne peut pas fonctionner avec perl 5.8. Or il dépend de perl = 5.6.1 Donc avec perl 5.8 la dépendance est satisfaite : donc bug de dépendance ou j'ai pas compris ce que vous vouliez dire ? -- Erwan
Re: Uploader dans stable (was: Re: knoppix ( limite hs !!! ))
Le Wed 25/06/2003, Denis Barbier disait Pour reprendre les points, * les taquets de version vers le bas plutôt que vers le haut Cette phrase seule ne suffit pas, il faut redéfinir le processus de migration unstable-testing-stable ou fournir un schéma complètement différent. En fait le problème n'est pas là. Il y a des cas (et des exemples ont été donnés avec caml ou perl) ou la dépendance doit se faire sur une version bien précise. Mais la dépendance qui est mise dans le paquet n'est que trop rarement la dépendance minimale. Si on a une lib en x en stable y en unstable et un programme P qui utilise cette lib, il faudrait que si P peut tourner avec la version x la dépendance inscrite dans son paquet soit sur x et non sur = y -- Erwan
Re: Uploader dans stable (was: Re: knoppix ( limite hs !!! ))
Le Wed 25/06/2003, Denis Barbier disait Mais à quel moment tu compiles eperl avec perl 5.8 ? Avant la mise à jour simultanée, c'est perl 5.6 qui est dans stable, Or vous dites qu'il faut compiler avec les dépendances de stable. Si je comprends bien eperl est buggué dans stable puisque la dépendance est perl =5.6.1-6 ? -- Erwan
Re: Uploader dans stable (was: Re: knoppix ( limite hs !!! ))
Le 25.06.03, Denis Barbier a tapoté : | On Wed, Jun 25, 2003 at 12:48:34AM +0200, Thomas Nemeth wrote: | Le 24.06.03, Denis Barbier a tapoté : | | | Il n'est pas possible de faire une mise à jour séquentielle, j'aimerais | | donc savoir comment ce cas est géré si on compile sur la base de stable. | | Où est le pb : il suffit d'upgrader les 2 en même temps... | | Mais à quel moment tu compiles eperl avec perl 5.8 ? Avant la mise à jour | simultanée, c'est perl 5.6 qui est dans stable, Or vous dites qu'il faut | compiler avec les dépendances de stable. Recompilation (automatique si possible) dans un arbre à part temporaire puis basculement de tous les nouveaux paquets dans l'arbre officiel. Thomas -- BOFH excuse #406: Bad cafeteria food landed all the sysadmins in the hospital.
Re: Uploader dans stable (was: Re: knoppix ( limite hs !!! ))
Le 25.06.03, Denis Barbier a tapoté : | * modulariser la distrib | Il y a des personnes qui essaient de pousser la création de projets | internes (Debian Jr., Debian-Med, Debian-Edu, Debian Desktop, etc). | Je ne sais pas si ces projets avancent. Mouais. Personnellement je doute ce leur viabilité à long terme : il serait peut-être plus adéquat de proposer une liste de paquets lors de l'installation en fonction du but, un peu comme tasksel... Thomas -- BOFH excuse #408: Computers under water due to SYN flooding.
Re: Uploader dans stable (was: Re: knoppix ( limite hs !!! ))
On Wed, Jun 25, 2003 at 07:30:36AM +0200, Erwan David wrote: Le Wed 25/06/2003, Denis Barbier disait Pour reprendre les points, * les taquets de version vers le bas plutôt que vers le haut Cette phrase seule ne suffit pas, il faut redéfinir le processus de migration unstable-testing-stable ou fournir un schéma complètement différent. En fait le problème n'est pas là. Il y a des cas (et des exemples ont été donnés avec caml ou perl) ou la dépendance doit se faire sur une version bien précise. Mais la dépendance qui est mise dans le paquet n'est que trop rarement la dépendance minimale. Si on a une lib en x en stable y en unstable et un programme P qui utilise cette lib, il faudrait que si P peut tourner avec la version x la dépendance inscrite dans son paquet soit sur x et non sur = y Non, ce n'est pas vrai, le probleme cite de X, et bien tu verra que meme en utilisant X 4.2.1 de sid, les dependances sont xlibs ( 4.1.0-1) ou quelque chose du style. Le probleme vient surtout du renomage des paquet de X lorsque Branden a re-organiser X pour la release de X 4. Il est sur que la xlib 4 et la xlib 3 sont compatibles, le probleme est que les package X 3 et X 4 ne contenait pas les memes librairies au meme endroit, et de plus s'appellait differement. De plus, dans woody, si tu tient vraiment a utiliser X 3.3.6, il te suffit d'installer le package xserver-v3 correspondant, et la xlibs 4.x, et cela marche sans probleme. Le probleme que tu a rencontre ne pouvait (ou ne peut encore, si comme Georges, tu utilise oldstable) venir que si tu essaye de faire tourner potato avec des bouts d'autre chose. Pour les autres cas, shlibdeps n'incremente la dependance que si le soname majeur change, et les dependances faite par le mainteneur du package sont soit justifie, soit des bugs qu'il faut soumettre. Il va de soit qu'il faut aussi pouvoir accepter la reponse du mainteneur dans ce cas, apres tout il a peut etre raison et vous tort finalement. Amicalement, Sven Luther
Re: Uploader dans stable (was: Re: knoppix ( limite hs !!! ))
Le 25.06.03, Sven Luther a tapoté : | On Wed, Jun 25, 2003 at 08:53:04AM +0200, Thomas Nemeth wrote: | Le 25.06.03, Denis Barbier a tapoté : | | | Mais à quel moment tu compiles eperl avec perl 5.8 ? Avant la mise à jour | | simultanée, c'est perl 5.6 qui est dans stable, Or vous dites qu'il faut | | compiler avec les dépendances de stable. | | Recompilation (automatique si possible) dans un arbre à part | temporaire puis basculement de tous les nouveaux paquets dans | l'arbre officiel. | | C'est bien ce qu'est fait pour unstable/testing, n'est-ce pas ? Oui :) C'est même où je voulais en venir... | Et t'est | tu poser la questions des auto-builders ? Tu ne peut pas faire cela dans | un arbre prive, car les autobuilders n'y on pas acces. Tiens !? Pourquoi ? | En fait, testing, avec ses imperfections et ses problemes de maturite | est ce que Erwan et Georges appels de leur voeux. Sur, on construit les | packages dans unstable, mais les nouveaux packages rentrent dans testing | au fur et a mesure lorsqu'ils sont prets. Mouais. Il y a tout de même des pbs : quand une nouvelle bibliothèque est mise à jour, tous les paquets qui en dépendent ne sont pas recompilés automatiquement avec. Pire : certains utilisent même plusieurs versions de la même bibliothèque !!! Dernier exemple en date : libpng. Je me retrouve avec libpng2, libpng3, libpng10-0 et libpng12-0. Thomas -- BOFH excuse #416: We're out of slots on the server
Re: Uploader dans stable (was: Re: knoppix ( limite hs !!! ))
On Wed, Jun 25, 2003 at 07:33:56AM +0200, Erwan David wrote: Le Wed 25/06/2003, Denis Barbier disait Mais à quel moment tu compiles eperl avec perl 5.8 ? Avant la mise à jour simultanée, c'est perl 5.6 qui est dans stable, Or vous dites qu'il faut compiler avec les dépendances de stable. Si je comprends bien eperl est buggué dans stable puisque la dépendance est perl =5.6.1-6 ? Non, c'est volontaire, donner des dependances plus strictes risque de provoquer des blocages et des dependances qui s'attendent circulairement. Pour ocaml, on a resolu le probleme en creant un package virtuel ocaml-3.06 et en dependant la dessus. Mis a part que les autobuilders n'apprecient pas les dependances virtuelles, et que James Troup c'est fache avec moi et m'a liste dans son killfile (chose hautement pas cool pour un developpeur debian, vue que James est responsable d'au moins deux autobuilders et de plus ftp-master, et approuve les nouveau packages). Donc, idealement, perl serait appelle perl-5.6 ou du moins aurai un provide virtuel perl-5.6 et les packages perl pourrait alors tout naturellement dependre de perl-5.6, et ne plus se poser de questions. Le probleme dans ceci est bien sur que le groupe de package ne peut alors migrer dans testing que d'un seul bloc, et si un seul d'entre eux est retenu pour une raison meme minime, alors c'est l'ensemble des paquets qui ne peuvent pas entrer dans testing. Les histoires de dependances sont affreusement complexes, et pleins de subtilites, et les penser les resoudre avec des yakas, c'est pas tres malin. BTW, Georges, tu pourrait proposer comme sujet de TER l'annee prochaine une analyse des dependances dans debian, avec un peu de recherche des problemes possibles, et de la sauce theorie des graphes pour assaissoner le tout, non ? Cela permettrait de depasser le stade des on-dit et des rumeurs dans ce cadre pour quelque chose d'un peu plus formel, non ? Amicalement, Sven Luther
Re: Uploader dans stable (was: Re: knoppix ( limite hs !!! ))
On Wed, Jun 25, 2003 at 08:53:04AM +0200, Thomas Nemeth wrote: Le 25.06.03, Denis Barbier a tapoté : | On Wed, Jun 25, 2003 at 12:48:34AM +0200, Thomas Nemeth wrote: | Le 24.06.03, Denis Barbier a tapoté : | | | Il n'est pas possible de faire une mise à jour séquentielle, j'aimerais | | donc savoir comment ce cas est géré si on compile sur la base de stable. | |Où est le pb : il suffit d'upgrader les 2 en même temps... | | Mais à quel moment tu compiles eperl avec perl 5.8 ? Avant la mise à jour | simultanée, c'est perl 5.6 qui est dans stable, Or vous dites qu'il faut | compiler avec les dépendances de stable. Recompilation (automatique si possible) dans un arbre à part temporaire puis basculement de tous les nouveaux paquets dans l'arbre officiel. C'est bien ce qu'est fait pour unstable/testing, n'est-ce pas ? Et t'est tu poser la questions des auto-builders ? Tu ne peut pas faire cela dans un arbre prive, car les autobuilders n'y on pas acces. En fait, testing, avec ses imperfections et ses problemes de maturite est ce que Erwan et Georges appels de leur voeux. Sur, on construit les packages dans unstable, mais les nouveaux packages rentrent dans testing au fur et a mesure lorsqu'ils sont prets. Amicalement, Sven Luther
Re: Uploader dans stable (was: Re: knoppix ( limite hs !!! ))
On Wed, 25 Jun 2003 00:58:27 +0200 [EMAIL PROTECTED] (Denis Barbier) wrote: C'est là où je voulais en venir. Dire qu'il suffit de compiler en stable pour résoudre beaucoup de problèmes était simpliste, cela pose d'autres problèmes, et il faut appréhender le tout, ce qui n'était manifestement pas le cas. Je le re-répète, je n'ai pas dis qu'il fallait rester scotcher à stable coûte que coûte (ça c'est TON interprétation), j'ai dis qu'il faut repartir de dépendances basses (ie. stables) pour reconstruire un paquet. Et faire les tests dans un contexte stable, puisque c'est ce qu'ont les users sur leurs machines. Le hic, c'est que même si un dd fait ça, arrivé sur les autobuilders c'est sid qui est en place (non?), donc EVIDEMMENT, il faut adapter globalement le processus. Compiler dans un contexte plutôt unstable pour obtenir une version stable, ben intuitivement j'ai l'impression que ça rallonge la «convergence»... Reviens sur l'exemple d'ocaml en byte-code, c'est similaire : certains paquets utilisent la libperl, et dépendent alors de la version de perl utilisée à la compilation, tout comme un programme ocaml en byte-code dépendra de la machine virtuelle. Tout comme j'ai jamais dis qu'il fallait pas tenir compte des contextes particuliers (perl c'est perl, ocaml c'est ocaml). Je ne les mets pas dans le même sac (pour essayer de coincer GM ;-) car pour ocaml, en terme de besoin utilisateur, on pourrait fournir du natif et éviter tout ce type de problème. Mais on le fait pas. Donc on change d'exemple. Et hop. A+ -- debfr-faq: http://savannah.nongnu.org/download/debfr-faq/html/ val-linux: http://phalompe.homeip.net:9673/val-linux perso: http://www3.inrets.fr/estas/mariano
Re: Uploader dans stable (was: Re: knoppix ( limite hs !!! ))
On Wed, 25 Jun 2003 01:36:42 +0200 Laurent Defours [EMAIL PROTECTED] wrote: Effectivement, je n'avais pas du tout compris la chose comme ça. En fait, je me plaçais dans l'optique de la version stable, et donc sans aucun nouveau paquet (officiel, s'entend) qui rentre (mais je crois comprendre que c'est ce que Georges aimerait voir changer, si je ne me trompe encore...). Ben tu te trompe. Sur la formulation. Je ne touche pas à la stable en place. Après tout. Je souhaite juste que la testing soit plutôt élaborée comme une évolution de cette stable plutôt que comme une stabilisation de sid. La Debian évolue beaucoup à intervalle large... Ell pourrait évoluer raisonnablement à intervalle plus court. La faire évoluer beaucoup à intervalle court me semble irréalisable (pas à cause de Debian en soit mais à cause du «bouillonnement» du logiciel libre) Et mes excuses à Georges pour avoir clos mon message un peu sèchement : même pas fait gaffe. ;-) Je ne rêve pas : le serveur de la liste met bien le lien vers la faq tout seul, désormais ? Ah ben ouai... zut, ça rigole plus alors... ;-) Pensez à lire la FAQ de la liste avant de poser une question : http://savannah.nongnu.org/download/debfr-faq/html/ M'en voudrez pas si je garde néanmoins le lien dans ma signature ;-) -- debfr-faq: http://savannah.nongnu.org/download/debfr-faq/html/ val-linux: http://phalompe.homeip.net:9673/val-linux perso: http://www3.inrets.fr/estas/mariano
Re: Uploader dans stable (was: Re: knoppix ( limite hs !!! ))
On Wed, Jun 25, 2003 at 09:13:59AM +0200, Thomas Nemeth wrote: Le 25.06.03, Sven Luther a tapoté : | On Wed, Jun 25, 2003 at 08:53:04AM +0200, Thomas Nemeth wrote: | Le 25.06.03, Denis Barbier a tapoté : | | | Mais à quel moment tu compiles eperl avec perl 5.8 ? Avant la mise à jour | | simultanée, c'est perl 5.6 qui est dans stable, Or vous dites qu'il faut | | compiler avec les dépendances de stable. | |Recompilation (automatique si possible) dans un arbre à part |temporaire puis basculement de tous les nouveaux paquets dans |l'arbre officiel. | | C'est bien ce qu'est fait pour unstable/testing, n'est-ce pas ? Oui :) C'est même où je voulais en venir... :))) | Et t'est | tu poser la questions des auto-builders ? Tu ne peut pas faire cela dans | un arbre prive, car les autobuilders n'y on pas acces. Tiens !? Pourquoi ? Heu, tu est serieux la ? Parceque les autobuilders n'utilisent que des sources officielles, comme il se doit, ils n'ont manifestement pas acces a ce que le distributeur a sur son disque dur, et pour les sources non-officielles, il y a bien sur le probleme de la securite, et que seul les uploads sur des sources officielles sont signer par les DDs, et de plus verifie pour des problemes legaux, de licence, de brevet, et de paranoia de l'administration US. | En fait, testing, avec ses imperfections et ses problemes de maturite | est ce que Erwan et Georges appels de leur voeux. Sur, on construit les | packages dans unstable, mais les nouveaux packages rentrent dans testing | au fur et a mesure lorsqu'ils sont prets. Mouais. Il y a tout de même des pbs : quand une nouvelle bibliothèque est mise à jour, tous les paquets qui en dépendent ne sont pas recompilés automatiquement avec. Pire : certains utilisent même plusieurs versions de la même bibliothèque !!! Oui, mais le nouveau schema des noms de libairie avec soname inclus resoud cela. toutes les librairies n'ont pas encore adapte le nouveau schema, ce qui pose probleme pour le moment, mais devrait bien marche. Bien sur, pour ocaml et d'autres cas interprete, le probleme n'est pas resolut, car il faut une double dependance. La version de compatibilite (equivalent du soname) et la version de l'interpreteur (bytecode ocaml et version perl par exemple). Dernier exemple en date : libpng. Je me retrouve avec libpng2, libpng3, libpng10-0 et libpng12-0. Oui, mais une fois que seul libpng10-0 et libpng12-0 existeront, le probleme ne se posera plus. Le probleme reel de libpng etait cependant que les environement de developement n'etait pas installable simultanement, et que certains packages qui devait travailler ensemble etait linker avec des versions differentes de libpng, ce qui posait probleme et illustre bien aussi la complexite des dependances. Le probleme est maintenant resolu grace au travail formidable du mainteneur libpng (euh, de celui qui a fait le travail en tout cas, je sais pas si c'est le mainteneur officiel ou pas). Amicalement, Sven Luther Thomas -- BOFH excuse #416: We're out of slots on the server -- Pensez à lire la FAQ de la liste avant de poser une question : http://savannah.nongnu.org/download/debfr-faq/html/ To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Uploader dans stable (was: Re: knoppix ( limite hs !!! ))
Le 25.06.03, Sven Luther a tapoté : | On Wed, Jun 25, 2003 at 09:13:59AM +0200, Thomas Nemeth wrote: | | Et t'est | | tu poser la questions des auto-builders ? Tu ne peut pas faire cela dans | | un arbre prive, car les autobuilders n'y on pas acces. | | Tiens !? Pourquoi ? | | Heu, tu est serieux la ? Parceque les autobuilders n'utilisent que des | sources officielles, comme il se doit, ils n'ont manifestement pas acces | a ce que le distributeur a sur son disque dur, et pour les sources Le distributeur et son disque dur ? Lorsque je parlais de faire un arbre temporaire, ça aurait été un arbre _officiel_ bien sûr. Ça implique une nouvelle façon de générer la distro comme en parlait Denis. | Dernier exemple en date : libpng. | Je me retrouve avec libpng2, libpng3, libpng10-0 et libpng12-0. | | Oui, mais une fois que seul libpng10-0 et libpng12-0 existeront, le | probleme ne se posera plus. Pourquoi _2_ versions ??? | Le probleme reel de libpng etait cependant que les environement de | developement n'etait pas installable simultanement, et que certains Simultanément ? Mais 1 seul devrait suffire ! Enfin... Tout dépend de ce que tu entends par environnement de développement. Les headers et bibliothèques ? | packages qui devait travailler ensemble etait linker avec des versions | differentes de libpng, ce qui posait probleme et illustre bien aussi la | complexite des dependances. Oui. | Le probleme est maintenant resolu grace au travail formidable du | mainteneur libpng (euh, de celui qui a fait le travail en tout cas, je | sais pas si c'est le mainteneur officiel ou pas). Pas vraiment résolu : il me reste toujours des paquets qui dépendent des vieilles versions et certains qui en dépendent de 2 à la fois ! Thomas -- BOFH excuse #434: Please state the nature of the technical emergency
Re: Uploader dans stable (was: Re: knoppix ( limite hs !!! ))
On 24 Jun 2003 23:51:59 +0200 Raphaël \SurcouF\ Bordet [EMAIL PROTECTED] wrote: qualité, il ne dit même pas qu'il faille faire des backports: donnes-lui la dernière version de Sylpheed dernier cri avec des dépendances sur stable, et il sera content. J'ai tout à fait compris ce qu'il désirait. Mais non tu n'as pas compris. Obtenir une sylpheed comme décrit ci-dessus ça prend 10mn. Obtenir une sylpheed avec le dernier cri sur toutes les libs, ça prend 3semaines. (au pif;-). Et en plus pour débugger t'es bien avancé car au lieu d'avoir un suspect (le noyau sylpheed) tu en as 12 (au pif ;-). Ça s'appelle la séparation des problèmes. C'est ce qu'on apprend aux stagiaires. Un problème à la fois. Qu'est-ce qui te retient encore au projet actuel ? Je ne vous comprends vraiment pas. J'aimerais bien que lui me réponde à ce sujet... Je vois pas en quoi j'aurais a expliquer mon attachement à Debian sur une liste Debian. Je peux toutefois balancer des généralités comme qui aime bien chatie bien ... ça te va? A+ -- debfr-faq: http://savannah.nongnu.org/download/debfr-faq/html/ val-linux: http://phalompe.homeip.net:9673/val-linux perso: http://www3.inrets.fr/estas/mariano
Re: Uploader dans stable (was: Re: knoppix ( limite hs !!! ))
Le Wed 25/06/2003, Sven Luther disait En fait, testing, avec ses imperfections et ses problemes de maturite est ce que Erwan et Georges appels de leur voeux. Sur, on construit les packages dans unstable, mais les nouveaux packages rentrent dans testing au fur et a mesure lorsqu'ils sont prets. Ou avant (cf perl 5.6/5.8)... Ce qui peut faire perdre des fonctionalités. -- Erwan
Re: Uploader dans stable (was: Re: knoppix ( limite hs !!! ))
On Wed, Jun 25, 2003 at 09:29:59AM +0200, Georges Mariano wrote: On Wed, 25 Jun 2003 01:36:42 +0200 Laurent Defours [EMAIL PROTECTED] wrote: Effectivement, je n'avais pas du tout compris la chose comme ça. En fait, je me plaçais dans l'optique de la version stable, et donc sans aucun nouveau paquet (officiel, s'entend) qui rentre (mais je crois comprendre que c'est ce que Georges aimerait voir changer, si je ne me trompe encore...). Ben tu te trompe. Sur la formulation. Je ne touche pas à la stable en place. Après tout. Je souhaite juste que la testing soit plutôt élaborée comme une évolution de cette stable plutôt que comme une stabilisation de sid. La Debian évolue beaucoup à intervalle large... Ell pourrait évoluer raisonnablement à intervalle plus court. La faire évoluer beaucoup à intervalle court me semble irréalisable (pas à cause de Debian en soit mais à cause du «bouillonnement» du logiciel libre) Oui, mais le probleme alors c'est que si tu ne fait evoluer stable que un peu, tu cours le risque de ne jamais entreprendre les evolutions plus importantes du logiciel libre. De plus tu diminue les periodes de tests. Amicalement, Sven Luther
Re: Uploader dans stable (was: Re: knoppix ( limite hs !!! ))
On Wed, Jun 25, 2003 at 09:29:31AM +0200, Georges Mariano wrote: On Wed, 25 Jun 2003 00:58:27 +0200 [EMAIL PROTECTED] (Denis Barbier) wrote: C'est là où je voulais en venir. Dire qu'il suffit de compiler en stable pour résoudre beaucoup de problèmes était simpliste, cela pose d'autres problèmes, et il faut appréhender le tout, ce qui n'était manifestement pas le cas. Je le re-répète, je n'ai pas dis qu'il fallait rester scotcher à stable coûte que coûte (ça c'est TON interprétation), j'ai dis qu'il faut repartir de dépendances basses (ie. stables) pour reconstruire un paquet. Et faire les tests dans un contexte stable, puisque c'est ce qu'ont les users sur leurs machines. Le hic, c'est que même si un dd fait ça, arrivé sur les autobuilders c'est sid qui est en place (non?), donc EVIDEMMENT, il faut adapter globalement le processus. Compiler dans un contexte plutôt unstable pour obtenir une version stable, ben intuitivement j'ai l'impression que ça rallonge la «convergence»... Tu sait que ce que tu propose est realisable, c'est pour cela qu'existe stable-proposed-update et testing-proposed-update. Le premier permet de compiler en stable, et est utiliser pour les mise a jours de stable, mais pourrait etre etendu a une serie de backport officiel. Cependant la question se pose alors si les packages dans testing-proposed-updates seront compiler que avec stable, ou alors avec stable + testing-proposed-updates. Dans le deuxieme cas, cela risque de poser rapidement des problemes, et le genre de mise a jour geante que tu souhaite eviter. C'est plus realisable pour stable que pour testing cependant. Ce qu'il faudrait c'est un certain nombre de developpeurs qui s'occupe de stable-proposed-updates, qu'il fasse une serie de NMU de ce genre, et/ou qu'il convainquent les mainteneurs de faire des retroportage officiel dasn stable-proposed-updates, avec attention et minutie, et cela ne s'appliquerait qu'a un nombre reduit de package susceptible d'etre backporte sans causer trop de degat. Si tu est interesse par ce genre de chose, tu est le bienvenu, mais parle en sur debian-devel (sur un ton non confrontationnel cependant si tu veut obtenir des resultats) et j'attendrait au moins l'accord de Martin Shulze, qui est le charge des revisions de stable (entre autre). Si tu veut te lancer, je te soutiendrait dans cette discussion, mais a nouveau, si tu n'est pas pret a mettre la main a la pate, cela ne vaut pas la peine de commencer cette discussion. Testing-proposed-updates quand a lui peut servir a effectuer des mises a jour de securite pour testing, qui serait bloque dans unstable par une dependance malencontreuse ou quelque chose du genre. Amicalement, Sven Luther
Re: Uploader dans stable (was: Re: knoppix ( limite hs !!! ))
On Wed, Jun 25, 2003 at 09:54:09AM +0200, Thomas Nemeth wrote: Le 25.06.03, Sven Luther a tapoté : | On Wed, Jun 25, 2003 at 09:13:59AM +0200, Thomas Nemeth wrote: | | Et t'est | | tu poser la questions des auto-builders ? Tu ne peut pas faire cela dans | | un arbre prive, car les autobuilders n'y on pas acces. | |Tiens !? Pourquoi ? | | Heu, tu est serieux la ? Parceque les autobuilders n'utilisent que des | sources officielles, comme il se doit, ils n'ont manifestement pas acces | a ce que le distributeur a sur son disque dur, et pour les sources Le distributeur et son disque dur ? Lorsque je parlais de faire un arbre temporaire, ça aurait été un arbre _officiel_ bien sûr. Ça implique une nouvelle façon de générer la distro comme en parlait Denis. Oui, bien sur, mais comme dis, il y a unstable pour cela. Je suis comme toi, je pense que une nouvelle etape du procede testing qui utiliserait des repertoire officielle de troisieme niveau pour les grands changement dans les packages serait le bienvenu. Mais ce n'est pas possible encore actuellement, peut etre apres la release de sarge, et de toute facon tant que quelq'un ne montre pas par l'exemple que cela marche, on ira pas loin. De plus, cela pose aussi un certain nombre de problemes. Car la migration de ces packages dans unstable poseront le meme genre de probleme que le passage de unstable a testing, ce qui risque de ne rien resoudre ne fin de compte, a moins de compiler dans ce troisieme niveau _tous_ les packages qui risquerait d'etre casse. C'est un changement a grande echelle que j'appelle de mes voeux, mais qui n'est pas encore mure aujourd'hui. |Dernier exemple en date : libpng. |Je me retrouve avec libpng2, libpng3, libpng10-0 et libpng12-0. | | Oui, mais une fois que seul libpng10-0 et libpng12-0 existeront, le | probleme ne se posera plus. Pourquoi _2_ versions ??? Parceque lipng10 et libpng12 sont de soname differents et donc incompatibles. Cependant il existe encore des packages qui utilisent libpng10 (ou libpng2 si tu veut), et qui ne peuve pas utiliser libpng12. Une fois tous ces packages recompile, libpng10 pourra disparaitre. Cependant, tous les trucs gtk/gnome 1.x utilisent encore libpng2, donc tu t'imagine bien que c'est pas demains la veille que cela arrivera. Cependant, maintenant que libpng10 et libpng12 ont des soname correcte, ils peuvent etre installe simultanement, et le probleme n'est plus aussi grave. Cette situation venait du fait que libpng ne gerait pas les soname correctement, et est donc plus du a un bug upstream qu'a un probleme debianesque. | Le probleme reel de libpng etait cependant que les environement de | developement n'etait pas installable simultanement, et que certains Simultanément ? Mais 1 seul devrait suffire ! Enfin... Tout dépend de ce que tu Voir plus haut. entends par environnement de développement. Les headers et bibliothèques ? Oui, bien sur. | packages qui devait travailler ensemble etait linker avec des versions | differentes de libpng, ce qui posait probleme et illustre bien aussi la | complexite des dependances. Oui. | Le probleme est maintenant resolu grace au travail formidable du | mainteneur libpng (euh, de celui qui a fait le travail en tout cas, je | sais pas si c'est le mainteneur officiel ou pas). Pas vraiment résolu : il me reste toujours des paquets qui dépendent des vieilles versions et certains qui en dépendent de 2 à la fois ! C'est resolu au niveau de la libpng, mais maintenant il faut que les packages qui dependent de libpng soit mise a jour. Cela peut prendre un temps variable et probablement relativement long. Amicalement, Sven Luther
Re: Uploader dans stable (was: Re: knoppix ( limite hs !!! ))
On Wed, Jun 25, 2003 at 10:15:48AM +0200, Erwan David wrote: Le Wed 25/06/2003, Sven Luther disait En fait, testing, avec ses imperfections et ses problemes de maturite est ce que Erwan et Georges appels de leur voeux. Sur, on construit les packages dans unstable, mais les nouveaux packages rentrent dans testing au fur et a mesure lorsqu'ils sont prets. Ou avant (cf perl 5.6/5.8)... Ce qui peut faire perdre des fonctionalités. C'est des cas exceptionnel, je ne suis pas du meme avis que aj sur ce point, mais tu a bien vu comment il a repondu a mon mail sur d-d. Cependant, cela reste des exception qui sont necessaire lorsque tu voit le schema global des choses, et elles sont uniquement la pour accelerer la prochaine release. Amicalement, Sven Luther
Re: Uploader dans stable (was: Re: knoppix ( limite hs !!! ))
Le 25.06.03, Sven Luther a tapoté : | On Wed, Jun 25, 2003 at 09:54:09AM +0200, Thomas Nemeth wrote: | | Lorsque je parlais de faire un arbre temporaire, ça aurait été | un arbre _officiel_ bien sûr. Ça implique une nouvelle façon de | générer la distro comme en parlait Denis. | | Oui, bien sur, mais comme dis, il y a unstable pour cela. Je suis comme Je sais : c'est pour ça que je voulais en venir à testing/unstable :) | resoudre ne fin de compte, a moins de compiler dans ce troisieme niveau | _tous_ les packages qui risquerait d'etre casse. C'est un changement a Voilà ! | grande echelle que j'appelle de mes voeux, mais qui n'est pas encore | mure aujourd'hui. dommage :( | Pourquoi _2_ versions ??? | | Parceque lipng10 et libpng12 sont de soname differents et donc | incompatibles. Cependant il existe encore des packages qui utilisent | libpng10 (ou libpng2 si tu veut), et qui ne peuve pas utiliser libpng12. | Une fois tous ces packages recompile, libpng10 pourra disparaitre. | Cependant, tous les trucs gtk/gnome 1.x utilisent encore libpng2, donc | tu t'imagine bien que c'est pas demains la veille que cela arrivera. C'est bien ce que je leur reproche : ils sont dans unstable/testing = ils devraient utiliser les dernières versions à leur dispositions, sinon ça ne rime plus à rien et ce découpage ne sert plus du tout... | Cependant, maintenant que libpng10 et libpng12 ont des soname correcte, | ils peuvent etre installe simultanement, et le probleme n'est plus aussi Mais moi je ne veux pas qu'ils soient installés simultanément. Avoir 2 fois la même chose (ou 2 trucs qui font la même chose) n'est pas fait pour m'enchanter (en l'occurence 4 fois, pour l'instant)... | grave. Cette situation venait du fait que libpng ne gerait pas les | soname correctement, et est donc plus du a un bug upstream qu'a un | probleme debianesque. Le pb debianesque c'est que des packages dépendent de toutes les versions... Dont certains de plusieurs en même temps. | | Le probleme est maintenant resolu grace au travail formidable du | | mainteneur libpng (euh, de celui qui a fait le travail en tout cas, je | | sais pas si c'est le mainteneur officiel ou pas). | | Pas vraiment résolu : il me reste toujours des paquets qui | dépendent des vieilles versions et certains qui en dépendent | de 2 à la fois ! | | C'est resolu au niveau de la libpng, mais maintenant il faut que les | packages qui dependent de libpng soit mise a jour. Cela peut prendre un | temps variable et probablement relativement long. C'est là qu'il devrait y avoir un auto-builder ! Thomas -- Je cherche un Cray T3E pas trop cher, je suis prêt à me déplacer en province (j'ai une 504 break, ça devrait aller). Ah oui, si vous avez une manette de jeu ça serait encore mieux. -+- C in fr.comp.ordinosaures - téra-optimisme de rigueur -+-
Re: Uploader dans stable (was: Re: knoppix ( limite hs !!! ))
On Wed, Jun 25, 2003 at 11:24:44AM +0200, Thomas Nemeth wrote: | | Le probleme est maintenant resolu grace au travail formidable du | | mainteneur libpng (euh, de celui qui a fait le travail en tout cas, je | | sais pas si c'est le mainteneur officiel ou pas). | |Pas vraiment résolu : il me reste toujours des paquets qui |dépendent des vieilles versions et certains qui en dépendent |de 2 à la fois ! | | C'est resolu au niveau de la libpng, mais maintenant il faut que les | packages qui dependent de libpng soit mise a jour. Cela peut prendre un | temps variable et probablement relativement long. C'est là qu'il devrait y avoir un auto-builder ! Non, car les autobuilders ne vont pas decider de recompiler automatiquement. Et c'est pas toujours possible de toute facon, donc le mainteneur est le mieux a meme pour resoudre ce probleme. La manip a faire dans ce cas la c'est de faire des bugreport pour chacun des packages concerne, peut-etre meme automatiquement, mais je commencerait par l'un d'entre eux juste pour voir, puis si le mainteneur ne reagit pas au bout de une ou deux semaines, plutot deux d'ailleurs, tu fait un NMU (si tu est DD bien sur, sinon, tu t'arrange avec un DD pour faire le NMU. Amicalement, Sven Luther
Re: Uploader dans stable (was: Re: knoppix ( limite hs !!! ))
Le 25.06.03, Sven Luther a tapoté : | On Wed, Jun 25, 2003 at 11:24:44AM +0200, Thomas Nemeth wrote: | | | | C'est resolu au niveau de la libpng, mais maintenant il faut que les | | packages qui dependent de libpng soit mise a jour. Cela peut prendre un | | temps variable et probablement relativement long. | | C'est là qu'il devrait y avoir un auto-builder ! | | Non, car les autobuilders ne vont pas decider de recompiler | automatiquement. Ils le devraient ! le paquet Machin a été mis à jour de la version A, à la version B -- tous les paquets qui dépendent de Machin = A doivent être recompilés. | Et c'est pas toujours possible de toute facon, donc le | mainteneur est le mieux a meme pour resoudre ce probleme. La manip a | faire dans ce cas la c'est de faire des bugreport pour chacun des | packages concerne, peut-etre meme automatiquement, mais je commencerait Oui, automatiquement serait la solution pour qu'on ne se fasse pas eng* à chaque message sur le sujet. | par l'un d'entre eux juste pour voir, puis si le mainteneur ne reagit | pas au bout de une ou deux semaines, plutot deux d'ailleurs, tu fait un | NMU (si tu est DD bien sur, sinon, tu t'arrange avec un DD pour faire le | NMU. Je ne suis pas DD. M'enfin, c'est certainement pas ça qui va régler le pb des dépendances histériques faites par les DD, comme kerberos pour postgresql et autres... Thomas -- panic(Tell me what a watchpoint trap is, and I'll then deal with such a beast...); 2.2.16 /usr/src/linux/arch/arch/sparc/kernel/traps.c
Re: Uploader dans stable (was: Re: knoppix ( limite hs !!! ))
On Wed, Jun 25, 2003 at 12:09:59PM +0200, Thomas Nemeth wrote: Le 25.06.03, Sven Luther a tapoté : | On Wed, Jun 25, 2003 at 11:24:44AM +0200, Thomas Nemeth wrote: | | | | C'est resolu au niveau de la libpng, mais maintenant il faut que les | | packages qui dependent de libpng soit mise a jour. Cela peut prendre un | | temps variable et probablement relativement long. | |C'est là qu'il devrait y avoir un auto-builder ! | | Non, car les autobuilders ne vont pas decider de recompiler | automatiquement. Ils le devraient ! le paquet Machin a été mis à jour de la version A, à la version B -- tous les paquets qui dépendent de Machin = A doivent être recompilés. | Et c'est pas toujours possible de toute facon, donc le ^ Je ne pense pas que ce soit quelque chose qui est automatisable, le changement de soname entraine une incompatibilite tant binaire que source, et on ne peut pas esperer qu'il suffise toujours de simplement recompiler les packages. Cela necessite intervention humaine pour etre sur. | par l'un d'entre eux juste pour voir, puis si le mainteneur ne reagit | pas au bout de une ou deux semaines, plutot deux d'ailleurs, tu fait un | NMU (si tu est DD bien sur, sinon, tu t'arrange avec un DD pour faire le | NMU. Je ne suis pas DD. Cela ne t'empeche pas de faire les bugreports, qui sont le plus important, les DD qui s'occupent du paquet se chargeront en general de resoudre le probleme. M'enfin, c'est certainement pas ça qui va régler le pb des dépendances histériques faites par les DD, comme kerberos pour postgresql et autres... Aucun idee, mais a nouveau, c'est un probleme specifique a un package, donc mail au mainteneur ou bug report. Amicalement, Sven Luther
Re: Uploader dans stable (was: Re: knoppix ( limite hs !!! ))
Le 25.06.03, Sven Luther a tapoté : | On Wed, Jun 25, 2003 at 12:09:59PM +0200, Thomas Nemeth wrote: | | | | Non, car les autobuilders ne vont pas decider de recompiler | | automatiquement. | | Ils le devraient ! | le paquet Machin a été mis à jour de la version A, à la version B | -- tous les paquets qui dépendent de Machin = A doivent être | recompilés. | | | Et c'est pas toujours possible de toute facon, donc le | ^ | | Je ne pense pas que ce soit quelque chose qui est automatisable, le | changement de soname entraine une incompatibilite tant binaire que | source, et on ne peut pas esperer qu'il suffise toujours de simplement | recompiler les packages. Cela necessite intervention humaine pour etre | sur. Il doit bien y avoir un moyen de le faire savoir aux DD qui s'occupent de paquets dépendant de ces mises-à-jour... | M'enfin, c'est certainement pas ça qui va régler le pb des | dépendances histériques faites par les DD, comme kerberos | pour postgresql et autres... | | Aucun idee, mais a nouveau, c'est un probleme specifique a un package, | donc mail au mainteneur ou bug report. Ce n'est pas un pb spécifique : c'est un cancer généralisé. Il y a plusieurs paquets qui en dépendent inutilement... Mais c'est d'une manière plus globale qu'est le problème : trop de dépendances rend la mise à jour du système encore plus complexe. Avec nettement moins de dépendances, ça rendrait le passage d'une version à une autre (que ce soit tant au niveau des paquets qu'au niveau de la distro complète) beaucoup plus simple, et moins plantogène. Le système de gestion des dépendances de Debian est le meilleur qui soit, mais ce genre de problème devrait pouvoir être règlé plus simplement... Thomas -- Ta mère elle s'attend à bronzer devant son Sun.
Re: Uploader dans stable (was: Re: knoppix ( limite hs !!! ))
Le Wed 25/06/2003, Sven Luther disait Aucun idee, mais a nouveau, c'est un probleme specifique a un package, donc mail au mainteneur ou bug report. Il y a 3 versions différentes de kerberos dans debian, des paquets aussi basiques que lprng ou xemacs imposent leur version de kerberos alors que 95% des utilisateurs n'en ont rien à foutre,j n'y connaissent rien et que ce genre de mécanisme mal utilisé conduit à ouvrir des trous de sécurité. J'ai ouvert un bug sur lprng. Pas encore de réponse du mainteneur. Pour xemacs je ne le fais pas car je n'utilise pas le paquet : les emacs debianisé sont vraiment trop différents de l'upstream. -- Erwan
Re: Uploader dans stable (was: Re: knoppix ( limite hs !!! ))
On Wed, Jun 25, 2003 at 02:34:05PM +0200, Thomas Nemeth wrote: Le 25.06.03, Sven Luther a tapoté : | On Wed, Jun 25, 2003 at 12:09:59PM +0200, Thomas Nemeth wrote: | | | | Non, car les autobuilders ne vont pas decider de recompiler | | automatiquement. | |Ils le devraient ! |le paquet Machin a été mis à jour de la version A, à la version B |-- tous les paquets qui dépendent de Machin = A doivent être |recompilés. | | | Et c'est pas toujours possible de toute facon, donc le | ^ | | Je ne pense pas que ce soit quelque chose qui est automatisable, le | changement de soname entraine une incompatibilite tant binaire que | source, et on ne peut pas esperer qu'il suffise toujours de simplement | recompiler les packages. Cela necessite intervention humaine pour etre | sur. Il doit bien y avoir un moyen de le faire savoir aux DD qui s'occupent de paquets dépendant de ces mises-à-jour... Oui, des bug reports (eventuellement automatise). |M'enfin, c'est certainement pas ça qui va régler le pb des |dépendances histériques faites par les DD, comme kerberos |pour postgresql et autres... | | Aucun idee, mais a nouveau, c'est un probleme specifique a un package, | donc mail au mainteneur ou bug report. Ce n'est pas un pb spécifique : c'est un cancer généralisé. Il Non, c'est une probleme specifique liee a postgresql et kerberos par exemple. y a plusieurs paquets qui en dépendent inutilement... Mais c'est d'une manière plus globale qu'est le problème : trop de dépendances rend la mise à jour du système encore plus complexe. Avec nettement moins de dépendances, ça rendrait le passage d'une version à une autre (que ce soit tant au niveau des paquets qu'au niveau de la distro complète) beaucoup plus simple, et moins plantogène. Oui, sur, mais tu ne ferrait jamais de changement alors. Le système de gestion des dépendances de Debian est le meilleur qui soit, mais ce genre de problème devrait pouvoir être règlé plus simplement... Et ils seront regle avant la release de sarge (dans un ans au pire, si les estimations sont exacte, quoique j'espere qu'on aurra pas besoin de 6 mois de freeze pour cela, comme l'estimation le pense. Amicalement, Sven Luther
Re: Uploader dans stable (was: Re: knoppix ( limite hs !!! ))
Le 25.06.03, Sven Luther a tapoté : | On Wed, Jun 25, 2003 at 02:34:05PM +0200, Thomas Nemeth wrote: | | | | Je ne pense pas que ce soit quelque chose qui est automatisable, le | | changement de soname entraine une incompatibilite tant binaire que | | source, et on ne peut pas esperer qu'il suffise toujours de simplement | | recompiler les packages. Cela necessite intervention humaine pour etre | | sur. | | Il doit bien y avoir un moyen de le faire savoir aux DD qui | s'occupent de paquets dépendant de ces mises-à-jour... | | Oui, des bug reports (eventuellement automatise). Oui : automatisés. Il est nécessaire que les DD mettent à jour leurs paquets sans qu'on ait à leur en faire la remarque... Sinon ils le prennent mal. | | M'enfin, c'est certainement pas ça qui va régler le pb des | | dépendances histériques faites par les DD, comme kerberos | | pour postgresql et autres... | | | | Aucun idee, mais a nouveau, c'est un probleme specifique a un package, | | donc mail au mainteneur ou bug report. | | Ce n'est pas un pb spécifique : c'est un cancer généralisé. Il | | Non, c'est une probleme specifique liee a postgresql et kerberos par | exemple. C'est lié surtout à kerberos qui est utilisé à tord et à travers. Et à la tendance fâcheuses de liée inutilement des paquets à des bibliothèques sans raison valable. Comme par exemple xemacs et openldap, kerberos et j'en passe. Même gimp y passe et dépend de... wget ! On aura tout vu. | y a plusieurs paquets qui en dépendent inutilement... Mais c'est | d'une manière plus globale qu'est le problème : trop de | dépendances rend la mise à jour du système encore plus complexe. | Avec nettement moins de dépendances, ça rendrait le passage d'une | version à une autre (que ce soit tant au niveau des paquets qu'au | niveau de la distro complète) beaucoup plus simple, et moins | plantogène. | | Oui, sur, mais tu ne ferrait jamais de changement alors. Bien sûr que si ! upgrade de la bibliothèque X = upgrade de tous les paquets qui en dépendent. Je ne vois pas en quoi le fait de _limiter_ les dépendances empêcherait de faire des changements. Je n'ai pas dit _fixer_ ni _interdire_ les dépendances, hein :) Simplement les limiter au strict nécessaire, libre aux utilisateurs avertis de se rajouter les dépendances qu'ils souhaitent, selon leurs besoins. | Le système de gestion des dépendances de Debian est le meilleur | qui soit, mais ce genre de problème devrait pouvoir être règlé | plus simplement... | | Et ils seront regle avant la release de sarge (dans un ans au pire, si | les estimations sont exacte, quoique j'espere qu'on aurra pas besoin de | 6 mois de freeze pour cela, comme l'estimation le pense. Connaissant les cycles de release de la distro depuis plusieurs années, j'ai tendance à croire que même 1 an est une limite basse ;) Thomas -- Ta mère pour sauver ses disquettes elle les met dans un coffre.
Re: Uploader dans stable (was: Re: knoppix ( limite hs !!! ))
On Wed, Jun 25, 2003 at 08:59:56AM +0200, Sven Luther wrote: On Wed, Jun 25, 2003 at 07:33:56AM +0200, Erwan David wrote: Le Wed 25/06/2003, Denis Barbier disait Mais à quel moment tu compiles eperl avec perl 5.8 ? Avant la mise à jour simultanée, c'est perl 5.6 qui est dans stable, Or vous dites qu'il faut compiler avec les dépendances de stable. Si je comprends bien eperl est buggué dans stable puisque la dépendance est perl =5.6.1-6 ? Non, c'est volontaire, donner des dependances plus strictes risque de provoquer des blocages et des dependances qui s'attendent circulairement. [...] Non ce n'est pas la raison, dans ce cas eperl dépend aussi de libperl5.6. Il faut donc effectivement que eperl rentre en même temps que perl dans testing, ce qui est possible avec le schéma actuel, pas si on compile en stable. Denis
Re: Uploader dans stable (was: Re: knoppix ( limite hs !!! ))
On Wed, Jun 25, 2003 at 11:24:44AM +0200, Thomas Nemeth wrote: [...] | Cependant, maintenant que libpng10 et libpng12 ont des soname correcte, | ils peuvent etre installe simultanement, et le probleme n'est plus aussi Mais moi je ne veux pas qu'ils soient installés simultanément. Avoir 2 fois la même chose (ou 2 trucs qui font la même chose) n'est pas fait pour m'enchanter (en l'occurence 4 fois, pour l'instant)... C'est marrant, il y en a qui râlent pour garder l'ancienne version, d'autres pour ne garder que la nouvelle, d'autres qui veulent tout, et d'autres qui râlent pour le plaisir. Ça va être difficile de contenter tout le monde. Denis
Re: Uploader dans stable (was: Re: knoppix ( limite hs !!! ))
On Wed, Jun 25, 2003 at 08:53:04AM +0200, Thomas Nemeth wrote: Le 25.06.03, Denis Barbier a tapoté : | On Wed, Jun 25, 2003 at 12:48:34AM +0200, Thomas Nemeth wrote: | Le 24.06.03, Denis Barbier a tapoté : | | | Il n'est pas possible de faire une mise à jour séquentielle, j'aimerais | | donc savoir comment ce cas est géré si on compile sur la base de stable. | |Où est le pb : il suffit d'upgrader les 2 en même temps... | | Mais à quel moment tu compiles eperl avec perl 5.8 ? Avant la mise à jour | simultanée, c'est perl 5.6 qui est dans stable, Or vous dites qu'il faut | compiler avec les dépendances de stable. Recompilation (automatique si possible) dans un arbre à part temporaire puis basculement de tous les nouveaux paquets dans l'arbre officiel. [...] Si tu te donnes la peine de formaliser cela (i.e. fournir des règles dictant comment les paquets sont compilés et quel est ensuite leur cheminement), je ne serai pas étonné que tu retombes sur ce qui existe actuellement. Denis
Re: Uploader dans stable (was: Re: knoppix ( limite hs !!! ))
Le Tue 24/06/2003, Raphaël SurcouF Bordet disait Le lun 23/06/2003 à 21:58, Georges Mariano a écrit : Franchement non, les machines tournaient correctement en 3.3.6. Mais comme je suis passé en xfree4.0 à cause des «sur-dépendances» ben effectivement au bout d'un moment on passe en woody. Un peu comme un windowsien qui s'accroche à son win95 qui marche bien mais qui fini par passer à win98 par la force des choses et pas vraiment parce qu'il le souhaite. Qu'est-ce qui t'oblige donc à mettre à jour si tu n'en as pas besoin ? Je ne comprends pas comment tu peux avoir des mises à jour non voulues... Tu dois le faire exprès, ce n'est pas possible. On peut avoir besoin de mises à jour partielles. Au boulout c'est OpenOffice 1.0.3 minimun par exemple... -- Erwan
Re: Uploader dans stable (was: Re: knoppix ( limite hs !!! ))
Le Tue 24/06/2003, Raphaël SurcouF Bordet disait D'après moi, ce n'est pas intéressant: ça mènerait à une debian à deux vitesses. C'est *déjà* le cas de par la volonté de debian. -- Erwan
Re: Uploader dans stable (was: Re: knoppix ( limite hs !!! ))
Le Tue 24/06/2003, Raphaël SurcouF Bordet disait Donc, tu ne fais que des paquets pour ton propre compte... Sympa... Vu l'anathème lancé sur les paquets non-officiels... -- Erwan
Re: Uploader dans stable (was: Re: knoppix ( limite hs !!! ))
On Mon, Jun 23, 2003 at 09:58:33PM +0200, Georges Mariano wrote: On Mon, 23 Jun 2003 20:28:11 +0200 Sven Luther [EMAIL PROTECTED] wrote: Vite ? Tu veut rire, oui, oui, c'était pour forcer le trait ... je parie que XFree86 fera une nouvelle release (4.4.0) avant que Debian n'aie de packages XFree86 4.3.0 dans sid. Un pari que je serait heureux de predre d'ailleurs. Tu crois pas si bien dire. Mon bateau a bien coulé. Il a suffit que je redémarre mon portable (avec xfree4.3 récupéré involontairement) pour que je constate que mon serveur X ne démarre pas vraiment... j'ai donc downgradé (technique du apt-cache policy + install version choisie) vers 4.2. J'ai fais une étape intermédiaire ... qui n'a pas durée (ça freeze aléatoirement). Je suis maintenant revenu en 4.1 et j'espère bien que sarge ne m'obligera pas a en sortir ;-) Plus de details veux tu, quelle carte graphique, quelle marque de portable, as tu fait un bugreport dans le bugzilla de XFree86 ? Je suis aussi upstream XFree86, et c'est le genre de chose que l'on ne peut pas laisser passer comme cela, si il y a un bug, bein, faut le corriger. Et c'est pourquoi tu install woody sur tes machines, non ? Franchement non, les machines tournaient correctement en 3.3.6. Mais comme je suis passé en xfree4.0 à cause des «sur-dépendances» ben effectivement au bout d'un moment on passe en woody. Un peu comme un windowsien qui s'accroche à son win95 qui marche bien mais qui fini par passer à win98 par la force des choses et pas vraiment parce qu'il le souhaite. Err, c'est pourquoi tu install woody plutot que sarge et sid. Amicalement, Sven Luther
Re: Uploader dans stable (was: Re: knoppix ( limite hs !!! ))
On Mon, Jun 23, 2003 at 09:41:26PM +0200, Erwan David wrote: Le Mon 23/06/2003, Denis Barbier disait Pour que les choses soient claires, la façon dont les paquets entrent dans la distribution testing est expliquée sur http://www.debian.org/devel/testing Avec le même exemple d'hevea, on voit qu'il est possible de mettre à jour ocaml et hevea sans que les paquets dans testing ne soient cassés, s'ils sont déplacés simultanément. J'aimerai avoir des explications similaires dans le cas où la compilation se fait sur la base de stable. Ou alors on admet que les paquets puissent être cassés pendant un laps de temps ? tu expliqueras donc pourquoi perlmagick est cassé dans testing celui en perl 5.8 ne pouvant être descendu à cause d'une dépendance sur lcms lui même bloqué parcequ'il dépend de libc6 2.3... T'est quand meme gonfler, Colin Watson te l'a expliquer a 2/3 reprise dans ton bugreport, et tu persiste a ne pas comprendre. Amicalement, Sven Luther
Re: Uploader dans stable (was: Re: knoppix ( limite hs !!! ))
On Tue, Jun 24, 2003 at 12:38:26AM +0200, Georges Mariano wrote: On Mon, 23 Jun 2003 23:59:38 +0200 [EMAIL PROTECTED] (Denis Barbier) wrote: Ce n'est qu'un exemple, choisi parce que nous le connaissons tous les deux. Il serait facile d'en trouver un autre équivalent, si celui-ci ne te plait pas, par exemple avec les modules binaires de perl. ben si, il me plait... mais c'est toi qui l'a choisi... Ben non, dans ton schmurf stable, il y a ocaml 3.04 ; si tu le remplaces par ocaml 3.06, toutes tes applis ocaml ne marchent plus. nan, pas si les applis sont compilées en natif... moi j'aimerai bien mais bon... j'ose pas demander ... ;-) Cela ne change rien. hevea pourrait prendre la meme solution sympa retenue par spamoracle, a savoir une package bytecode arch: all et un package natif arch: liste des arches natives. Marche tres bien. Mais bon, c'est au choix des mainteneurs de faire cela, et cela ne resoudrait pas le probleme de toute facon, car on est quand meme oblige de compiler en bytecode pour les arches non natives. Amicalement, Sven Luther
Re: Uploader dans stable (was: Re: knoppix ( limite hs !!! ))
On Mon, Jun 23, 2003 at 10:57:40PM +0200, Georges Mariano wrote: On Mon, 23 Jun 2003 21:32:56 +0200 [EMAIL PROTECTED] (Denis Barbier) wrote: Sauf que quand ocaml est upgradé, l'hevea dans cet espèce de stable est cassé ; si pour une raison quelconque il ne compile pas avec ocaml 3.06, il va rester cassé pour un bout de temps. Comme « continuité douce », on peut rêver mieux. Ah oui, c'est vrai, j'oubliais un truc... faut savoir qu'hevea peut-être compilé en natif (i.e ne pas nécessiter de dépendance sur ocaml) donc ce problème pourrait être éliminé ... ... sauf que, si je ne me trompe pas, les paquets relatifs a ocaml sont fournis en byte-code (donc avec une dépendance sur l'interpréteur ocaml). C'est un choix des mainteneurs. Le prix que les utilisateurs i386 payent pour les archi qui ne disposent pas de compilateur natif. admettons et abrégeons, il reste que : apt-cache show hevea Depends: gs, netpbm(=2:9.10-1), tetex-bin, ocaml-base-3.06-1 ^ (et non plus ocaml-base, !? j'y comprends plus rien) [euh dans ocaml-base-3.06, y'a ocamlrun-3.06 je suppose ?] Cela montre bien que tu ne lis pas les mails que je t'envoie, j'ai expliquer exactement cela dans un mail precedent. Si le package dependait de ocaml-base, qui a un moment est effectivement la machine virtuelle 3.06, alors lorsque je releaserait le package ocaml 3.07 ou un snapshot cvs d'ailleurs, la machine virtuelle serait soudainement celle de ocaml 3.07, et aucun programme bytecode ne marcherait plus. Et non, il n'y a pas encore ocamlrun-3.06 juste ocamlrun, mais j'espere changer cela, mais bon, c'est une decision lourde de consequence qu'il faut prendre avec upstream. alors c'est faisable non ? tiens en ce moment je me bats avec ça : Oui, une transition douce pour ocaml est faissable, mais elle demande que plusieurs packages soit installable simultanement, ce qui a son tour demande qu'une decision soit prise au niveau de l'ensemble de la comunaute ocaml, et que les sources soit patche. apt-cache search automake automake - A tool for generating GNU Standards-compliant Makefiles. automake1.4 - A tool for generating GNU Standards-compliant Makefiles. automake1.5 - A tool for generating GNU Standards-compliant Makefiles. automake1.6 - A tool for generating GNU Standards-compliant Makefiles. automake1.7 - A tool for generating GNU Standards-compliant Makefiles Oui, et tu est au courrant que le mainteneur de automake a decide d'en supprimer un, et qu'il a donner une longue explication a ce propos sur d-d et d-d-a. Amicalement, Sven Luther
Re: Uploader dans stable (was: Re: knoppix ( limite hs !!! ))
On Tue, Jun 24, 2003 at 12:38:26AM +0200, Georges Mariano wrote: On Mon, 23 Jun 2003 23:59:38 +0200 [EMAIL PROTECTED] (Denis Barbier) wrote: Ce n'est qu'un exemple, choisi parce que nous le connaissons tous les deux. Il serait facile d'en trouver un autre équivalent, si celui-ci ne te plait pas, par exemple avec les modules binaires de perl. ben si, il me plait... mais c'est toi qui l'a choisi... Ben non, dans ton schmurf stable, il y a ocaml 3.04 ; si tu le remplaces par ocaml 3.06, toutes tes applis ocaml ne marchent plus. nan, pas si les applis sont compilées en natif... moi j'aimerai bien mais bon... j'ose pas demander ... ;-) Très bien, puisque tu veux t'en sortir avec une pirouette, prenons l'exemple de perl. Le paquet eperl dépend de libperl5.6 dans stable et libperl5.8 dans unstable. J'attends donc que tu nous expliques comment mettre à jour perl et eperl si les paquets sont compilés en stable. Pour l'instant, il n'y a que des yaka, mais certainement pas des propositions concrètes. ben c'est toi qui nous a dit que plusieurs versions c'était mal !! Ah ? Tu peux dire dans quel message ? Denis
Re: Uploader dans stable (was: Re: knoppix ( limite hs !!! ))
Le mar 24/06/2003 à 07:45, Erwan David a écrit : Le Tue 24/06/2003, Raphaël SurcouF Bordet disait D'après moi, ce n'est pas intéressant: ça mènerait à une debian à deux vitesses. C'est *déjà* le cas de par la volonté de debian. Donc, vous en rajoutez une troisième... -- Raphaël SurcouF Bordet [EMAIL PROTECTED]
Re: Uploader dans stable (was: Re: knoppix ( limite hs !!! ))
On Tue, 24 Jun 2003 08:03:03 +0200 Sven Luther [EMAIL PROTECTED] wrote: redémarre mon portable (avec xfree4.3 récupéré involontairement) pour que je constate que mon serveur X ne démarre pas vraiment... j'ai donc downgradé (technique du apt-cache policy + install version choisie) vers 4.2. J'ai fais une étape intermédiaire ... qui n'a pas durée (ça freeze aléatoirement). Je suis maintenant revenu en 4.1 et j'espère bien que sarge ne m'obligera pas a en sortir ;-) Plus de details veux tu, quelle carte graphique, quelle marque de portable, as tu fait un bugreport dans le bugzilla de XFree86 ? Je suis aussi upstream XFree86, et c'est le genre de chose que l'on ne peut pas laisser passer comme cela, si il y a un bug, bein, faut le corriger. c'est ce que j'ai fait ;-) retour en 4.1. passer à win98 par la force des choses et pas vraiment parce qu'il le souhaite. Err, c'est pourquoi tu install woody plutot que sarge et sid. c'est vrai on peut aussi passer a win2000 et winXP ;-) Bon aller, c'est bon là ... on va fatiguer les autres ;-) A+ -- debfr-faq: http://savannah.nongnu.org/download/debfr-faq/html/ val-linux: http://phalompe.homeip.net:9673/val-linux perso: http://www3.inrets.fr/estas/mariano
Re: Uploader dans stable (was: Re: knoppix ( limite hs !!! ))
Le Tue 24/06/2003, Sven Luther disait On Mon, Jun 23, 2003 at 09:41:26PM +0200, Erwan David wrote: Le Mon 23/06/2003, Denis Barbier disait Pour que les choses soient claires, la façon dont les paquets entrent dans la distribution testing est expliquée sur http://www.debian.org/devel/testing Avec le même exemple d'hevea, on voit qu'il est possible de mettre à jour ocaml et hevea sans que les paquets dans testing ne soient cassés, s'ils sont déplacés simultanément. J'aimerai avoir des explications similaires dans le cas où la compilation se fait sur la base de stable. Ou alors on admet que les paquets puissent être cassés pendant un laps de temps ? tu expliqueras donc pourquoi perlmagick est cassé dans testing celui en perl 5.8 ne pouvant être descendu à cause d'une dépendance sur lcms lui même bloqué parcequ'il dépend de libc6 2.3... T'est quand meme gonfler, Colin Watson te l'a expliquer a 2/3 reprise dans ton bugreport, et tu persiste a ne pas comprendre. Justement, dans woody, il a a été décidé qu'on admettait que les paquets soient cassés. Maintenant j'ai toujours pas compris pourquoi il fallait absolument passer à perl 5.8 dans testing en cassant les dépendances, dont certaines viennent d'une dépendance à la libc6 de unstable... Bref il a été décidé de casser sarge en passant en perl 5.8 avant de passer en glibc 2.3 -- Erwan
Re: Uploader dans stable (was: Re: knoppix ( limite hs !!! ))
On Tue, 24 Jun 2003 08:51:05 +0200 [EMAIL PROTECTED] (Denis Barbier) wrote: nan, pas si les applis sont compilées en natif... moi j'aimerai bien mais bon... j'ose pas demander ... ;-) Très bien, puisque tu veux t'en sortir avec une pirouette, Ce que tu appelles une pirouette c'est ce que les utilisateurs aiment bien avoir sur leur machine, des applis en natif qui vont vite (quand le natif est possible évidemment). Tu vas pas en revenir, quand je développe en OCaml j'aime bien sa vitesse d'exécution ;-) prenons l'exemple de perl. Le paquet eperl dépend de libperl5.6 dans stable et libperl5.8 dans unstable. J'attends donc que tu nous expliques comment mettre à jour perl et eperl si les paquets sont compilés en stable. je connais pas ces applis, ... quelle est la motivation de l'upgrade ? ben c'est toi qui nous a dit que plusieurs versions c'était mal !! Ah ? Tu peux dire dans quel message ? oups, désolé, c'est Sven, à force je vous confonds;-) A+ -- debfr-faq: http://savannah.nongnu.org/download/debfr-faq/html/ val-linux: http://phalompe.homeip.net:9673/val-linux perso: http://www3.inrets.fr/estas/mariano
Re: Uploader dans stable (was: Re: knoppix ( limite hs !!! ))
On Tue, Jun 24, 2003 at 09:21:33AM +0200, Erwan David wrote: Le Tue 24/06/2003, Sven Luther disait On Mon, Jun 23, 2003 at 09:41:26PM +0200, Erwan David wrote: Le Mon 23/06/2003, Denis Barbier disait Pour que les choses soient claires, la façon dont les paquets entrent dans la distribution testing est expliquée sur http://www.debian.org/devel/testing Avec le même exemple d'hevea, on voit qu'il est possible de mettre à jour ocaml et hevea sans que les paquets dans testing ne soient cassés, s'ils sont déplacés simultanément. J'aimerai avoir des explications similaires dans le cas où la compilation se fait sur la base de stable. Ou alors on admet que les paquets puissent être cassés pendant un laps de temps ? tu expliqueras donc pourquoi perlmagick est cassé dans testing celui en perl 5.8 ne pouvant être descendu à cause d'une dépendance sur lcms lui même bloqué parcequ'il dépend de libc6 2.3... T'est quand meme gonfler, Colin Watson te l'a expliquer a 2/3 reprise dans ton bugreport, et tu persiste a ne pas comprendre. Justement, dans woody, il a a été décidé qu'on admettait que les Pas dans woody, dans testing. paquets soient cassés. Maintenant j'ai toujours pas compris pourquoi il fallait absolument passer à perl 5.8 dans testing en cassant les dépendances, dont certaines viennent d'une dépendance à la libc6 de unstable... Parceque l'on souhaite avoir perl 5.8 dans sarge lorsque sarge sera releaser. Bref il a été décidé de casser sarge en passant en perl 5.8 avant de passer en glibc 2.3 N'importe quoi, cela fais des mois que sarge est en glibc 2.3. Amicalement, Sven Luther
Re: Uploader dans stable (was: Re: knoppix ( limite hs !!! ))
Le Tue 24/06/2003, Sven Luther disait Parceque l'on souhaite avoir perl 5.8 dans sarge lorsque sarge sera releaser. Bref il a été décidé de casser sarge en passant en perl 5.8 avant de passer en glibc 2.3 N'importe quoi, cela fais des mois que sarge est en glibc 2.3. ALors je ne comprends pas pourquoi lcms ne passe pas en sarge (ce qui bloque perlmagick...) http://packages.qa.debian.org/l/lcms.html 132 jours pas de bug bloquant la seule dépendance est libc6 =2.3.1-1 Y'a un truc qui a du m'échapper... -- Erwan
Re: Uploader dans stable (was: Re: knoppix ( limite hs !!! ))
On Tue, Jun 24, 2003 at 12:29:51AM +0200, Georges Mariano wrote: hmm, si tous le monde reste en libc6-2 (hypothèse d'école évidemment) pourquoi intégrer la libc6-368 dans la Debian/Core ... ? dans ton scenario, j'ai comme l'impression que la 368 resterait dans testing non (pas suffisamment testée)? Avec les dépendances minimales, un paquet n'est vraiment intégré que si le besoin est indiscutable. Avec les dépendances maximales, un paquet est intégré... parce qu'il existe (une sorte de push). Le problème reste le même: le jour ou libc6-368 devient indispensable à foobar-3.2.25, elle commence à être utilisée par les utilisateurs (non-DD) de foobar sans avoir été vraiment testée. En ce moment, les DDs sont obligés de tester les nouvelles versions avant les utilisateurs. Il pourrait également y avoir un problème où la distribution n'avance plus du tout: après tout, mon système marche tout aussi bien avec un noyau 2.2, peut-être même un 2.0... et tu es passé de potato à woody comment ? un beau matin d'une potato pure à une woody pure ou petit à petit (comme moi)? update puis dist-upgrade, et deux nuits d'upload (rhaa, bientôt l'adsl). Si je me souviens bien, seul la config de diald fût cassée. .Y -- Marbles should be kept together.
Re: Uploader dans stable (was: Re: knoppix ( limite hs !!! ))
On Tue, Jun 24, 2003 at 01:59:07AM +0200, Raphaël SurcouF Bordet wrote: Un backport ne sera jamais mieux qu'un paquet officiel de la stable. C'est justement ce que tu ne comprends pas: l'assurance qualité de debian joue sur ce plan-là. Ce que toi tu ne comprends pas, c'est que Georges suggère une nouvelle manière de produire Debian, en se basant plus sur stable et moins sur sortir une nouvelle version complète. Il ne dit pas qu'il ne faut pas faire d'assurance qualité, il ne dit même pas qu'il faille faire des backports: donnes-lui la dernière version de Sylpheed dernier cri avec des dépendances sur stable, et il sera content. C'en est à se demander pourquoi tu persistes encore à utiliser Debian... Qu'est-ce qui te retient encore au projet actuel ? Je ne vous comprends vraiment pas. L'aspect social bien sûr: quelle autre distribution permet des débats intéressants et interminables sur leur mailing listes? :-) /Y -- Marbles should be kept together.
Re: Uploader dans stable (was: Re: knoppix ( limite hs !!! ))
On Tue, Jun 24, 2003 at 08:51:05AM +0200, Denis Barbier wrote: Très bien, puisque tu veux t'en sortir avec une pirouette, prenons l'exemple de perl. Le paquet eperl dépend de libperl5.6 dans stable et libperl5.8 dans unstable. J'attends donc que tu nous expliques comment mettre à jour perl et eperl si les paquets sont compilés en stable. Pour l'instant, il n'y a que des yaka, mais certainement pas des propositions concrètes. Dans un concept de stable glissant (ou de nouvelles versions apparaissent dans stable, mais les dépendances restent les plus vieilles), libperl5.8 serait disponible avant, donc on utiliserait eperl(Depends:=libperl5.6) avec libperl5.8, puis plus tard quand eperl(Depends:=libperl5.8) sort, seul eperl est upgradé. C'est simplement une façon complètement différente de suivre la progression de la distribution, et d'après ce que dit Sven c'est ce que testing aurait du être. /Y -- Marbles should be kept together.
Re: Uploader dans stable (was: Re: knoppix ( limite hs !!! ))
On Tue, Jun 24, 2003 at 10:50:36AM +0200, Erwan David wrote: Le Tue 24/06/2003, Sven Luther disait Parceque l'on souhaite avoir perl 5.8 dans sarge lorsque sarge sera releaser. Bref il a été décidé de casser sarge en passant en perl 5.8 avant de passer en glibc 2.3 N'importe quoi, cela fais des mois que sarge est en glibc 2.3. ALors je ne comprends pas pourquoi lcms ne passe pas en sarge (ce qui bloque perlmagick...) http://packages.qa.debian.org/l/lcms.html 132 jours pas de bug bloquant la seule dépendance est libc6 =2.3.1-1 Y'a un truc qui a du m'échapper... Un petit tour a : http://bjorn.haxx.se/debian/ te donnera la page suivante : http://bjorn.haxx.se/debian/testing.pl?package=lcms Faire passer lcms dans testing rendra 308 packages non-installable dans testing. La page dis alpha, mais c'est uniquement parceque les architectures sont teste de maniere sequentielles, et comme alpha est la premiere d'entre eux. Je suppose que la raison reel derriere cela c'est que les 308 packages en questions ne fonctionneront pas avec la nouvelle version de lcms, et doivent donc etre recompiler ou quelque chose du genre, et que leur version dans unstable soit aussi pret a remplacer la version dans testing. Tout cela est bien sur explique dans la documentation de la distribution testing : http://www.debian.org/devel/testing Il est dommage que le script de bjorn ne soit pas disponible directement depuis le PTS, mais bon, cela viendra peut-etre. Amicalement, Sven Luther
Re: Uploader dans stable (was: Re: knoppix ( limite hs !!! ))
* Sven Luther [EMAIL PROTECTED] [2003-06-23 13:09] : On Mon, Jun 23, 2003 at 10:53:07AM +0200, Georges Mariano wrote: [...] tu rigole ?? Il y avait deux version de X disponibles la 3.3.6 et la 4.0. Il y avait deux manière de régler facilement le problème de pas mal de dépendance (je simplifie) soit 3.3.6 provides 4.0, et ça marchait bien sauf pour quelques applis pointues et là fallait passer en (vrai) 4.0 : _uniquement si nécessaire_ soit 4.0 provides 3.3.6 et là, de toute manière tu passes en 4.0 même si t'as pas besoin Ca c'est des connerie, excuse moi, mais tu est vraiment butter. La meilleure maniere c'est de garder le serveur X 3.3.6, vu que c'est celui la que tu pense marche le mieux, et d'installer les bibliotheques X 4.x, celle qui satisfont les dependances dont tu a besoin. Et je doute tres fort qu'il y ai un quelconque changement de ressource entre les bibliotheques, Xlibs 3.x et les 4.x. Le serveur je ne dis pas, et encore je ne suis pas sur que ce soit le cas, mais les biblliotheques, vraiment, elle ne devrait pas utiliser plus de ressources. Là, je confirme ce que dit Sven : il est parfaitement possible d'utiliser un vieux PC (pour moi, un PPro 200 avec une carte vidéo S3 Trio32 non supportée par XFree 4.1) avec woody et XFree 3.3 (je n'ai pas pensé à utiliser le pilote vesa de XFree 4) et d'utiliser tout de même les programmes compilés par rapport à la xlib 4 (on parlait de dillo, il me semble, qui est tout à fait utilisable et rapide sur ce genre de machine). Fred -- LA FAQ d-u-f ? http://savannah.nongnu.org/download/debfr-faq/html/
Re: Uploader dans stable (was: Re: knoppix ( limite hs !!! ))
On Tue, Jun 24, 2003 at 10:33:41AM +0100, Yves Rutschle wrote: On Tue, Jun 24, 2003 at 08:51:05AM +0200, Denis Barbier wrote: Très bien, puisque tu veux t'en sortir avec une pirouette, prenons l'exemple de perl. Le paquet eperl dépend de libperl5.6 dans stable et libperl5.8 dans unstable. J'attends donc que tu nous expliques comment mettre à jour perl et eperl si les paquets sont compilés en stable. Pour l'instant, il n'y a que des yaka, mais certainement pas des propositions concrètes. Dans un concept de stable glissant (ou de nouvelles versions apparaissent dans stable, mais les dépendances restent les plus vieilles), libperl5.8 serait disponible avant, donc on utiliserait eperl(Depends:=libperl5.6) avec libperl5.8, puis plus tard quand eperl(Depends:=libperl5.8) sort, seul eperl est upgradé. Même réponse que pour Thomas Nemeth, l'exécutable eperl compilé avec perl 5.6 ne fonctionnera pas quand perl 5.8 remplace perl 5.6 dans cette « stable » glissante. Démonstration: - copie d'un eperl de stable dans unstable - $ ./eperl ./eperl: error while loading shared libraries: libperl.so.5.6: cannot open shared object file: No such file or directory Il n'est pas possible de faire une mise à jour séquentielle, j'aimerais donc savoir comment ce cas est géré si on compile sur la base de stable. Denis
Re: Uploader dans stable (was: Re: knoppix ( limite hs !!! ))
On Tue, Jun 24, 2003 at 09:32:52AM +0200, Georges Mariano wrote: [...] prenons l'exemple de perl. Le paquet eperl dépend de libperl5.6 dans stable et libperl5.8 dans unstable. J'attends donc que tu nous expliques comment mettre à jour perl et eperl si les paquets sont compilés en stable. je connais pas ces applis, ... quelle est la motivation de l'upgrade ? [...] Puisque les cas concrets ne t'intéressent pas, soient A et B deux paquets, qui seront supposés pour simplifier avoir les mêmes noms en paquets source et binaire. On note vA1 et vA2 les versions des programmes (choisies par upstream) de A, et dA1 et dA2 les numéros de révision Debian. On introduit des notations similaires pour le paquet B. Supposons que A a besoin pour s'exécuter de la version de B qui a servi lors de la compilation, et plus précisément de vB, quel que soit dB. Les paquets se trouvent dans stable dans les versions vA1dA1 et vA2dA2. Maintenant, les utilisateurs demandent à ce que les nouvelles versions soient mises dans la version stable, il suffit de regarder www.apt-get.org pour s'en rendre compte. Il faut donc réussir à faire rentrer A vA2 et B vB2 dans stable. Pour cela, on me propose de faire rentrer d'abord B vB2. Mais alors A vA1 ne peut plus marcher avec B vB2, et cette distribution soi-disant plus stable est obligatoirement cassée. On me répondra que le paquet A vA2 va suivre rapidement, mais rien n'indique qu'il soit facile de compiler A vA2 avec B vB2, on risque donc d'avoir un cassage pendant une durée non négligeable. Pourquoi ce problème n'existe-t-il pas si on compile en unstable ? Il existe, et unstable est cassé de la même façon, mais ces paquets cassés ne vont pas rentrer dans testing. On commence par faire rentrer B vB2, puis on compile A vA2 avec B vB2, et lorsque tout est bon, les programmes peuvent migrer vers testing. La distribution unstable joue son rôle de tampon. Avec la « solution » proposée, ce rôle de tampon sera joué par la distribution stable. Brillante idée ! Denis
Re: Uploader dans stable (was: Re: knoppix ( limite hs !!! ))
Le mar 24/06/2003 à 11:23, Yves Rutschle a écrit : On Tue, Jun 24, 2003 at 01:59:07AM +0200, Raphaël SurcouF Bordet wrote: Un backport ne sera jamais mieux qu'un paquet officiel de la stable. C'est justement ce que tu ne comprends pas: l'assurance qualité de debian joue sur ce plan-là. Ce que toi tu ne comprends pas, c'est que Georges suggère une nouvelle manière de produire Debian, en se basant plus sur stable et moins sur sortir une nouvelle version complète. Il ne dit pas qu'il ne faut pas faire d'assurance qualité, il ne dit même pas qu'il faille faire des backports: donnes-lui la dernière version de Sylpheed dernier cri avec des dépendances sur stable, et il sera content. J'ai tout à fait compris ce qu'il désirait. Non seulement, ça risque, comme je le disais, de produire une debian à deux vitesses (unstable et stable+backport) mais en outre, rien ne permet d'affirmer que les backports en question seront de la même qualité. Pourquoi a-t-il abandonné sa propre production ? C'en est à se demander pourquoi tu persistes encore à utiliser Debian... Qu'est-ce qui te retient encore au projet actuel ? Je ne vous comprends vraiment pas. L'aspect social bien sûr: quelle autre distribution permet des débats intéressants et interminables sur leur mailing listes? :-) J'aimerais bien que lui me réponde à ce sujet... -- Raphaël SurcouF Bordet [EMAIL PROTECTED]
Re: Uploader dans stable (was: Re: knoppix ( limite hs !!! ))
On Tue, 24 Jun 2003 22:59:45 +0200 [EMAIL PROTECTED] (Denis Barbier) wrote: tampon. Avec la « solution » proposée, ce rôle de tampon sera joué par la distribution stable. Brillante idée ! Bon écoute Denis, le principal reproche initial n'était pas celui d'avoir des distribs temporairement cassées mais celui d'avoir des dépendances minimales (proposer xfree4.0 _là où_ 3.6 suffit, proposer libperl5.8 _là où_ libperl5.6 suffit etc etc) je ne demande pas à courir après les dernières versions de tout ce qui bouge sur le net... depuis que j'utilise Debian j'entend régulièrement que tout le monde aimerait raccourcir les délais de release mais je vois mal comment on espère atteindre cet objectif sans changer au moins un peu le processus de release. donc il y a des idées à creuser * les taquets de version vers le bas plutôt que vers le haut * modulariser la distrib (pourquoi pas?) (ne pas vouloir tout packager pour toutes les archi si on en a pas les moyens) * avoir une politique stricte pour définir ce que l'on veut livrer à court terme (par exemple décider [par un comité] que libperl5.8 ce sera pour plus tard et finir le boulot sur libperl5.6) comme tout bouge trop vite, on se retrouve régulièrement avec le dilemment «on peut raisonnablement pas sortir la prochaine Debian sans y mettre machine-super-baleze-k+1» (gnome k+1, kde k+1, perl k+1, ...) En rejetant localement chaque piste on risque de passer à côté d'un progrès global... Tiens une réflexion, en passant, Sven indique qu'il ne veut pas cautionner une duplication d'effort inutile. Ok, je comprends. Alors que devient le boulot fait pour perl5.6 ?? si je comprends bien, perl5.8 n'est pas compatible perl5.6 ?? (on ne pouvait pas avoir perl-5.6 et perl-5.8 ?) Pour ma culture, je suis pas perlien ... A+ -- debfr-faq: http://savannah.nongnu.org/download/debfr-faq/html/ val-linux: http://phalompe.homeip.net:9673/val-linux perso: http://www3.inrets.fr/estas/mariano
Re: Uploader dans stable (was: Re: knoppix ( limite hs !!! ))
Le 24.06.03, Denis Barbier a tapoté : | On Tue, Jun 24, 2003 at 10:33:41AM +0100, Yves Rutschle wrote: | | Dans un concept de stable glissant (ou de nouvelles | versions apparaissent dans stable, mais les dépendances | restent les plus vieilles), libperl5.8 serait disponible | avant, donc on utiliserait eperl(Depends:=libperl5.6) avec | libperl5.8, puis plus tard quand eperl(Depends:=libperl5.8) | sort, seul eperl est upgradé. | | Même réponse que pour Thomas Nemeth, l'exécutable eperl compilé | avec perl 5.6 ne fonctionnera pas quand perl 5.8 remplace perl 5.6 | dans cette « stable » glissante. | Démonstration: | - copie d'un eperl de stable dans unstable | - $ ./eperl | ./eperl: error while loading shared libraries: libperl.so.5.6: cannot open shared object file: No such file or directory | | Il n'est pas possible de faire une mise à jour séquentielle, j'aimerais | donc savoir comment ce cas est géré si on compile sur la base de stable. Où est le pb : il suffit d'upgrader les 2 en même temps... Thomas
Re: Uploader dans stable (was: Re: knoppix ( limite hs !!! ))
On Tue, Jun 24, 2003 at 11:44:35PM +0200, Georges Mariano wrote: [...] donc il y a des idées à creuser * les taquets de version vers le bas plutôt que vers le haut * modulariser la distrib (pourquoi pas?) (ne pas vouloir tout packager pour toutes les archi si on en a pas les moyens) * avoir une politique stricte pour définir ce que l'on veut livrer à court terme (par exemple décider [par un comité] que libperl5.8 ce sera pour plus tard et finir le boulot sur libperl5.6) comme tout bouge trop vite, on se retrouve régulièrement avec le dilemment «on peut raisonnablement pas sortir la prochaine Debian sans y mettre machine-super-baleze-k+1» (gnome k+1, kde k+1, perl k+1, ...) En rejetant localement chaque piste on risque de passer à côté d'un progrès global... C'est là où je voulais en venir. Dire qu'il suffit de compiler en stable pour résoudre beaucoup de problèmes était simpliste, cela pose d'autres problèmes, et il faut appréhender le tout, ce qui n'était manifestement pas le cas. Pour reprendre les points, * les taquets de version vers le bas plutôt que vers le haut Cette phrase seule ne suffit pas, il faut redéfinir le processus de migration unstable-testing-stable ou fournir un schéma complètement différent. * modulariser la distrib Il y a des personnes qui essaient de pousser la création de projets internes (Debian Jr., Debian-Med, Debian-Edu, Debian Desktop, etc). Je ne sais pas si ces projets avancent. * [...] définir ce que l'on veut livrer à court terme Oui, avoir des objectifs me semble relever du bon sens. On ne peut pas dire que ce soit le cas actuellement. Tiens une réflexion, en passant, Sven indique qu'il ne veut pas cautionner une duplication d'effort inutile. Ok, je comprends. Alors que devient le boulot fait pour perl5.6 ?? Comprends pas, il n'y a pas de problème avec perl. Il est rentré dans testing au forceps, mais c'est à cause de dépendances avec d'autres paquets. si je comprends bien, perl5.8 n'est pas compatible perl5.6 ?? Non, pas pour les modules compilés, ni les programmes utilisant la libperl. (on ne pouvait pas avoir perl-5.6 et perl-5.8 ?) Pour ma culture, je suis pas perlien ... Reviens sur l'exemple d'ocaml en byte-code, c'est similaire : certains paquets utilisent la libperl, et dépendent alors de la version de perl utilisée à la compilation, tout comme un programme ocaml en byte-code dépendra de la machine virtuelle. Ce n'est qu'un exemple, si tu me réponds que tu veux de l'ocaml natif, on discutera de perl. Denis
Re: Uploader dans stable (was: Re: knoppix ( limite hs !!! ))
On Wed, Jun 25, 2003 at 12:48:34AM +0200, Thomas Nemeth wrote: Le 24.06.03, Denis Barbier a tapoté : | On Tue, Jun 24, 2003 at 10:33:41AM +0100, Yves Rutschle wrote: | | Dans un concept de stable glissant (ou de nouvelles | versions apparaissent dans stable, mais les dépendances | restent les plus vieilles), libperl5.8 serait disponible | avant, donc on utiliserait eperl(Depends:=libperl5.6) avec | libperl5.8, puis plus tard quand eperl(Depends:=libperl5.8) | sort, seul eperl est upgradé. | | Même réponse que pour Thomas Nemeth, l'exécutable eperl compilé | avec perl 5.6 ne fonctionnera pas quand perl 5.8 remplace perl 5.6 | dans cette « stable » glissante. | Démonstration: | - copie d'un eperl de stable dans unstable | - $ ./eperl | ./eperl: error while loading shared libraries: libperl.so.5.6: cannot open shared object file: No such file or directory | | Il n'est pas possible de faire une mise à jour séquentielle, j'aimerais | donc savoir comment ce cas est géré si on compile sur la base de stable. Où est le pb : il suffit d'upgrader les 2 en même temps... Mais à quel moment tu compiles eperl avec perl 5.8 ? Avant la mise à jour simultanée, c'est perl 5.6 qui est dans stable, Or vous dites qu'il faut compiler avec les dépendances de stable. Denis
Re: Uploader dans stable (was: Re: knoppix ( limite hs !!! ))
Le lundi 23 juin 2003, à 22:17, Denis Barbier écrivait : On Mon, Jun 23, 2003 at 03:37:24PM +0200, Laurent Defours wrote: Si c'est B.v1 qui se trouve dans ta version de la distribution et que B.v2 n'y est pas, il me semble franchement irresponsable de faire une dépendance vers B.v2. Mais dans ton idée, le paquet A.v1 lui-même ne fait pas exactement partie de cette version de la distribution, je me trompe ? Oui, mais les explications étaient tellement peu claires que ce n'est pas étonnant. Voici un autre exemple qui en reprend (je crois) l'idée. Les informations du paquet Debian perl 5.8 contiennent : Replaces: perl-5.005 ( 6), perl-5.6 ( 6), perl-doc ( 5.8.0-1), libdigest-md5-perl, libmime-base64-perl, libtime-hires-perl Provides: perl5, libdigest-md5-perl, libmime-base64-perl, libtime-hires-perl Conflicts: perl-5.004 ( 6), perl-5.005 ( 6), perl-5.6 ( 6), perl-doc ( 5.8.0-1), libdigest-md5-perl ( 2.20-1), libmime-base64-perl ( 2.12-1), libtime-hires-perl ( 1.20-1) Cela signifie que les modules (au sens Perl du terme) Digest::MD5, Mime::Base64 et Time::Hires font maintenant partie du paquet perl, et ne sont plus mis dans des paquets séparés. Un développeur veut mettre un nouveau paquet dans Debian, qui contient un script utilisant un de cas modules (si le paquet existait avant woody, il déclarait ces dépendances et le développeur n'aura pas l'idée de les enlever). Il met une dépendance sur perl sans se rendre compte que cette dépendance ne sera pas suffisante si on installe sur stable ou testing. Et comme le paquet ne déclare pas une dépendance sur perl = 5.8, il peut rentrer dans testing alors que perl 5.6 y est toujours. Effectivement, je n'avais pas du tout compris la chose comme ça. En fait, je me plaçais dans l'optique de la version stable, et donc sans aucun nouveau paquet (officiel, s'entend) qui rentre (mais je crois comprendre que c'est ce que Georges aimerait voir changer, si je ne me trompe encore...). Quand au cas que tu exposes, j'avoue ne l'avoir pas envisagé. Sauf si on est un génie en expert logiciel, on comprend aisément que c'est symétrique : si le développeur teste dans stable, rien ne garantit que ça marchera à 100% dans unstable ou testing. Les utilisateurs en UTF-8 en savent peut-être quelque chose. C'est bas, ça... Le problème est donc réel, mais la solution proposée n'en est pas une. Je te remercie pour tes éclaircissements. Et mes excuses à Georges pour avoir clos mon message un peu sèchement : je m'étais tapé un millier de message de la liste en retard environ, et j'étais comme qui dirait un tantinet excédé (même en ayant l'effacement facile). Je ne rêve pas : le serveur de la liste met bien le lien vers la faq tout seul, désormais ? -- Laurent
Re: Uploader dans stable (was: Re: knoppix ( limite hs !!! ))
On Mon, 23 Jun 2003 01:55:37 +0200 Laurent Defours [EMAIL PROTECTED] wrote: Le lundi 23 juin 2003, à 01:11, Georges Mariano écrivait : Crois moi sur parole ;-) Non. (et je suis pas DD) ça change tout... ;-) alors voilà (c'est long...): Ça se passe en (plutôt) oldstable [je suis en potato, woody vient de sortir] Je souhaite installer le paquet A.v1. J'installe, je lance le programme correspondant A, et boum ça plante. C'est du perl, j'ai un message sur le fichier fB, qui appartient au paquet B (que j'ai en version mettons v1...) Pourtant, je vais voir dans le paquet les dépendances sont satisfaites... A depends de B-v1. Alors ? Juste pour voir, apt-get install B -t sarge Je récupère la B-v2 Je relance A, ça marche!! Utilisateur docile : bugreport, Cher DD adoré, faut mettre une dépendance sur B.v2 et non pas B.v1. Voilà... On est content. C'est tout ? Non. Que s'est-il passé ? Proposition de scénario. Le DD a fait une 1ère version, il y a un certain temps avec une dépendance sur B.v1 (pour x raisons, ça marchait). Ensuite, comme tout DD qui se respecte, il suit la meute et upgrade régulièrement ça machine, tout évolue (paquet A et paquet B). Nouvelle version du paquet A construite dans le contexte sid comme il se doit mais avec B-v2 maintenant. Petit test de A. ok, ça marche. Paquet dans sid, personne ne voit rien tout les lemmings de cet acabit sont en sid ... ça arrive dans testing... j'installe chez moi et boum, ça plante. Durée du test : 2mn. J'ai une furieuse envie de laisser les DDs finir l'explication ;-) Explication : toutes les dépendance ne sont pas calculées automatiquement, en particulier ... ?? Celles pour les paquets qui dépendent d'un interpréteur. En effet, les dépendances automatiques sont calculées à partir des liens de liaisons binaires-librairies, donc dans le cas de paquets perl/python/... par exemple... ben ça coince. Faut faire évoluer à la main... et c'est d'autant plus difficile que l'organisation (découpage en paquet) évolue. Chacun est libre d'utiliser woody ou sarge ou sid mais pour faire un paquet, il vaut mieux se replacer dans le contexte stable pour détecter les dépendances minimales (c'est à dire plutôt celles qui sont en cours chez les utilisateurs... concept bien trop subtil pour un DD/sid j'en conviens). Pourquoi je détecte le bug grossier en 2mn et pas le DD ? Parce que je suis en stable et lui en sid... = un DD devrait travailler dans un chroot qu'il fait évoluer en fonction des paquets qu'il construit (et teste) et rien de plus. Cela permettra que _ses_ dépendances (manuelles) soient spécifiées au plus juste. Ça sera déjà un paquet de bug en moins. Mais je crois pas que le problème soit technique, en fait. Le DD doit être en général quelqu'un de très technique (on dit péjorativement bidouilleur). À l'aise uniquement dans le dernier cri, le passé pour lui est obsolète. Ce qui lui faut c'est du sid. Bah, ça se comprend. Sincèrement. Par contre, construire dans stable, bof, mouai, ça manque d'adrénaline. Sauf que c'est le plus stable. Et c'est là l'essentiel de ma critique, on ne dit pas que l'on mets les besoins utilisateurs et la stabilité de la distrib sont prioritaires (et toutes les distributions disent la même chose ;-) quand on demande aux DD de bosser dans sid. Ça, c'est une arnaque. On confond utilisateurs et mainteneurs. A+ -- debfr-faq: http://savannah.nongnu.org/download/debfr-faq/html/ val-linux: http://phalompe.homeip.net:9673/val-linux perso: http://www3.inrets.fr/estas/mariano
Re: Uploader dans stable (was: Re: knoppix ( limite hs !!! ))
On Mon, Jun 23, 2003 at 01:06:35AM +0200, Georges Mariano wrote: On Sun, 22 Jun 2003 23:15:35 +0200 Sven Luther [EMAIL PROTECTED] wrote: Oui et non, les nom des packages de XFree 3.x etait different, ce qui pose probleme. Et de toute facon, xfree 3, surtout pour la xlib, est antique, il y a vraiment aucun avantage a l'utiliser encore. et zou, tout le monde suit ?? et tu dis quoi à la personne qui a juste de quoi se payer un petit portable, qui était en potato, et qui peut pas installer la dernière version de dillo/woody car il faut xfre4.1, i.e asphyxier ça machine ? Comprend pas, les dernieres versions de xfree86 devrait etre toutes aussi performante et pas forcement necessite plus de ressources que xfree 3. Sur, j'ai pas essayer, mais j'ai l'intention d'installer X 4.3 sur mon portable 486 avec 300Mo de disque et 12Mo de ram. Donc, si tu a du detail pour l'asphyxie en question, ce serait sympa de le partager. De plus, il existe des packages X 3.x meme dans sid et sarge encore. Et il ne devrait pas y avoir de probleme a faire tourner un serveur X 3.x avec une xlibs plus moderne, c'est l'avantage du modele client/serveur de X. (c'est du vécu...) Ben tu lui dis que Debian ne le concerne plus. Super. Non, bien sur, beaucoup de gens dans ce cas font comme toi, et n'upgrade pas. Moi meme j'etait en train de reflechir a utiliser un fbdev puis DirectFB et XDirectFB au dessus comme serveur X, qui est beaucoup plus leger, mais bon je ne suis pas sur qu'il existe un driver fbdev pour les cartes graphiques WD utilise dans les vieux compaq. M'enfin, c'est sûr que pour si peut ça vaut pas la peine d'arrêter la belle mécanique Debian... Je te comprends. Et puis tu as raison, c'est pas grave si on perd un utilisateur de ce type (un peu fauché sur les bords) puisqu'on va en gagner sur 10 architectures supplémentaires ... Non, bien sur, mais en fait je doute qu'il s'agisse reellement d'un probleme, et si s'en est un, alors il faut soumettre un bugreport contre X. Amicalement, Sven Luther
Re: Uploader dans stable (was: Re: knoppix ( limite hs !!! ))
Le Mon 23/06/2003, Sven Luther disait De plus, il existe des packages X 3.x meme dans sid et sarge encore. Et il ne devrait pas y avoir de probleme a faire tourner un serveur X 3.x avec une xlibs plus moderne, c'est l'avantage du modele client/serveur de X. Mais imposer des dépendances sur une version plus récente que celle de stable quand ce n'est pas nécessaire va imposer de se procurer nettement plus de paquets. Ceux qui sont en RTC apprécieront de télécharger 15 Mo de plus juste parceque les dépendances spécifient une version plus récente que nécessaire... -- Erwan
Re: Uploader dans stable (was: Re: knoppix ( limite hs !!! ))
Le 22.06.03, Denis Barbier a tapoté : | Oui, mais je n'ai pas de chance, tu as cité la moitié du paragraphe où je | pose la question, ce qui le rend inintelligible, et tu n'y réponds même pas. | Le revoici donc en intégralité : | Prenons un exemple : hevea. Suivant ton raisonnement, il sera compilé avec | ocaml 3.04 (version dans stable). En parallèle, ocaml est aussi mis à jour, | en 3.06. Mais manque de bol, cet hevea refusera de tourner avec cet ocaml, | c'est pourquoi il y a une dépendance sur la version d'ocaml utilisée. | Comment faire alors pour qu'ocaml 3.06 rentre dans la prochaine version | stable, sans casser hevea ? Où est cette « continuité douce » promise ? Faut remettre à jour hevea après upgrade d'ocaml... En fait, l'idéal serait d'avoir une distro debian-source afin de placer totomatiquement les dépendances sur ce que l'on a effectivement installé, et recompiler automatiquement tout ce qui dépend d'un paquet qu'on vient de mettre à jour... Ce qui est tout de même gênant : après tout si on choisi une distro binaire c'est pas pour se taper les compils à chaque upgrade :( Thomas -- La Cabale m'a tuer. -+- PL in: Guide du Cabaliste Usenet - La Cabale persiffle et saigne -+-
Re: Uploader dans stable (was: Re: knoppix ( limite hs !!! ))
On 23 Jun 2003 04:07:44 +0200 Raphaël \SurcouF\ Bordet [EMAIL PROTECTED] wrote: Que veux-tu dire par ne pas compiler dans sid ? Je rejoins Sven dans sa réponse: les backports n'ont rien d'officiel. Les paquets ne sont pas validés par les responsables qualité, etc, etc... oui, mais çe ne t'intrigue pas que ce soit ce que les users recherchent ? ce que je ne comprends pas c'est pourquoi le backport est tellement décrié par les DDs, parce que ce n'est pas la philosophie Debian ? et alors ? un backport bien fait a besoin de _moins_ de validation (puisqu'il y a moins de choses qui bouge dans le contexte de construction) En outre, je pense que les backports, aussi pratiques soient-ils pour deux ou trois paquets, peuvent avoir de sérieuses conséquences quant au délai de la prochaine release. Mais puisque je te dis que ça ne m'intéresse pas de débugger une distribution qui ne correspond pas à mes besoins d'user!! Je vois pas pourquoi je m'amuserai à regarder python4.78, si je sais pertinemment que mon appli python se contente de python2.2 (j'exagère;-) paquet passe plus rapidemment dans la version dite testing. Conséquence indirecte: la nouvelle version stable peut être retardée. Cercle vicieux: tu continues donc dans ta lancée et conserver ta vieillestable et donc, tes backports... Elle est pas vieille, je peux backporter (par ex) sylpheed dernier cri sans problème. Oui, mais ce noyage de poisson est pourtant vrai. Ils sont toujours bénévoles, prennent sur leurs temps libres, c'est leur passion et ils préfèrent que tu prennes part au projet Mais j'y prends part (j'espère), à ma façon... qui peut déplaire ;-) Ne reçois-tu jamais de retours de la part de tes fameux backport ?... j'en fais plus... et ils n'étaient pas fameux comme tu dis, juste pratiques. Je le redis, il n'y a pas grand mérite à rejouer une mécanique de compilation de paquet... Faut juste choisir le contexte. A+ -- debfr-faq: http://savannah.nongnu.org/download/debfr-faq/html/ val-linux: http://phalompe.homeip.net:9673/val-linux perso: http://www3.inrets.fr/estas/mariano
Re: Uploader dans stable (was: Re: knoppix ( limite hs !!! ))
On Mon, 23 Jun 2003 09:40:45 +0200 Sven Luther [EMAIL PROTECTED] wrote: Comprend pas, les dernieres versions de xfree86 devrait etre toutes aussi performante et pas forcement necessite plus de ressources que ^ Je ne veux pas de pas forcément lorsque je __sais__ que ce n'est pas nécessaire. Pas envie de réinstaller la machine si, manque de bol, ben si ça coince !!... Et ça n'est absolument une consolation de se dire que maintenant on va pouvoir dire à Sven que ça marche effectivement pas... xfree 3. Sur, j'ai pas essayer, mais j'ai l'intention d'installer X 4.3 sur mon portable 486 avec 300Mo de disque et 12Mo de ram. Donc, si tu a du detail pour l'asphyxie en question, ce serait sympa de le partager. Si tu trouves normal de vouloir mettre X4.3 sur ce genre de machine, amuse toi bien ;-) [à la louche, tu perds déjà min 30Mo de disque entre 3.3.6 et 4.1] Ben asphyxie sur tous les points : disque / ram /cpu Alors que le portable fonctionne nickel en 3.3.6 et qu'il est pas prévu d'en faire un client Quake !! Non, bien sur, beaucoup de gens dans ce cas font comme toi, et n'upgrade pas. Non non, c'est __bien plus grave__, il ne s'agissait pas de moi mais d'un ami a qui j'avais dit tu verras Linux ça tourne bien sur une petite config et en plus avec la nouvelle Debian t'es blindé ... Ben non :-(( [Je crois que j'ai backporté sur une autre machine et transféré, c'est à dire que j'ai fais le boulot que naïvement je pensais être l'apanage de Debian.] Non, bien sur, mais en fait je doute qu'il s'agisse reellement d'un probleme, et si s'en est un, alors il faut soumettre un bugreport contre X. tu rigole ?? Il y avait deux version de X disponibles la 3.3.6 et la 4.0. Il y avait deux manière de régler facilement le problème de pas mal de dépendance (je simplifie) soit 3.3.6 provides 4.0, et ça marchait bien sauf pour quelques applis pointues et là fallait passer en (vrai) 4.0 : _uniquement si nécessaire_ soit 4.0 provides 3.3.6 et là, de toute manière tu passes en 4.0 même si t'as pas besoin Laquelle fut choisie ? De toute manière c'est du passé. A+ -- debfr-faq: http://savannah.nongnu.org/download/debfr-faq/html/ val-linux: http://phalompe.homeip.net:9673/val-linux perso: http://www3.inrets.fr/estas/mariano
Re: Uploader dans stable (was: Re: knoppix ( limite hs !!! ))
On Mon, Jun 23, 2003 at 10:19:02AM +0200, Erwan David wrote: Le Mon 23/06/2003, Sven Luther disait De plus, il existe des packages X 3.x meme dans sid et sarge encore. Et il ne devrait pas y avoir de probleme a faire tourner un serveur X 3.x avec une xlibs plus moderne, c'est l'avantage du modele client/serveur de X. Mais imposer des dépendances sur une version plus récente que celle de stable quand ce n'est pas nécessaire va imposer de se procurer Dis moi quelle package _de stable_ impose une version plus recente que celle disponible _dans stable_. Cite moi un seul exemple de cet etat des chose, et on en reparle. nettement plus de paquets. Ceux qui sont en RTC apprécieront de télécharger 15 Mo de plus juste parceque les dépendances spécifient une version plus récente que nécessaire... Ils ont qu'a attendre que la prochaine release sorte avec les nouvelles versions si ils ne peuvent pas se permettre de faire les mise a jour des dependances. Tu veut voir une copie de ma facture wanadoo de lorsque j'avait pas encore l'ADSL et de tout ce que j'ai payer pour uploader des packages a debian ? Et des gros packages en plus. Est-ce que je suis venu pleurer pour cela ? Amicalement, Sven Luther
Re: Uploader dans stable (was: Re: knoppix ( limite hs !!! ))
On Mon, Jun 23, 2003 at 09:23:38AM +0200, Georges Mariano wrote: On Mon, 23 Jun 2003 01:55:37 +0200 Laurent Defours [EMAIL PROTECTED] wrote: Le lundi 23 juin 2003, à 01:11, Georges Mariano écrivait : Crois moi sur parole ;-) Non. (et je suis pas DD) ça change tout... ;-) alors voilà (c'est long...): Ça se passe en (plutôt) oldstable [je suis en potato, woody vient de sortir] Je souhaite installer le paquet A.v1. J'installe, je lance le programme correspondant A, et boum ça plante. C'est du perl, j'ai un message sur le fichier fB, qui appartient au paquet B (que j'ai en version mettons v1...) Pourquoi ne pas utiliser les vrais nom de packages ? Il s'agit probablement d'un cas pathologique, que tu generalise un peu facilement ici. Pourtant, je vais voir dans le paquet les dépendances sont satisfaites... A depends de B-v1. Alors ? Juste pour voir, apt-get install B -t sarge Je récupère la B-v2 Je relance A, ça marche!! Utilisateur docile : bugreport, Cher DD adoré, faut mettre une dépendance sur B.v2 et non pas B.v1. Voilà... On est content. C'est tout ? Non. Que s'est-il passé ? Proposition de scénario. Le probleme est une mauvaise manip du cote du DD en question, je suis sur que le probleme n'apparait pas sur d'autres arches, qui sont auto-built. Moi lorsque je prepare un upload a stable-proposed-updates, je le construit dans un pbuilder bien sur, ou sur une machine stable de debian, et le probleme ne se pose pas. Le DD a fait une 1ère version, il y a un certain temps avec une dépendance sur B.v1 (pour x raisons, ça marchait). Ensuite, comme tout DD qui se respecte, il suit la meute et upgrade régulièrement ça machine, tout évolue (paquet A et paquet B). Nouvelle version du paquet A construite dans le contexte sid comme il se doit mais avec B-v2 maintenant. Petit test de A. ok, ça marche. Paquet dans sid, personne ne voit rien tout les lemmings de cet acabit sont en sid ... ça arrive dans testing... j'installe chez moi et boum, ça plante. Durée du test : 2mn. Erreur, cela ne peut pas arriver dans testing sans que B-v2 y arrive aussi, car c'est comme cela que marche les testing script, meme pire, il ne peut pas mettre de nouveaux packages en testing si ils cassent quoi que ce soit en testing. J'ai une furieuse envie de laisser les DDs finir l'explication ;-) Explication : toutes les dépendance ne sont pas calculées automatiquement, en particulier ... ?? Celles pour les paquets qui dépendent d'un interpréteur. En effet, les dépendances automatiques sont Et alors, ils ne sont certe pas calcule automatiquement, mais cela c'est le probleme du packageur et du packageur de l'interpreteur, qui devrait resoudre cela a la main, ou alors trouver une solution. Comme exemple, les packages ocaml bytecode dependent de la version de ocaml-base avec laquelle ils ont ete compiler. Donc ils ne peuvent pas simplement dependre de ocaml-base, mais doivent dependre soit de ocaml-base (= v), ocaml-base ( v+1) ou alors de ocaml-base-v comme c'est le cas maintenant. Mais je me rappelle que tu a raler tres fort lorsqu'on a fait cela, parceque tu avait du mal a backporter les packages en question. calculées à partir des liens de liaisons binaires-librairies, donc dans le cas de paquets perl/python/... par exemple... ben ça coince. Faut faire évoluer à la main... et c'est d'autant plus difficile que l'organisation (découpage en paquet) évolue. Chacun est libre d'utiliser woody ou sarge ou sid mais pour faire un paquet, il vaut mieux se replacer dans le contexte stable pour détecter les dépendances minimales (c'est à dire plutôt celles qui sont en cours chez les utilisateurs... concept bien trop subtil pour un DD/sid j'en conviens). N'importe quoi. Aucun package ne sera jamais ajouter a stable, donc il n'y a aucun interet a faire de nouveau paquet pour stable. De la meme maniere, il est extremement rare qu'une nouvelle version d'un paquet soit ajouter a stable, donc pourquoi faire ce que tu propose ? Meme lorsque j'ai preparer le package ocaml 3.04-14 pour woody 3.0r1 (woody avait 3.04-12 qui avait, pas un bug, mais un probleme dans la migration vers 3.06-x), j'ai compiler les packages dans un pbuilder, puis je suis aller les construire a la main dans chacune des architecture qui n'avait pas d'autobuilders pour stable-proposed-updates, et j'ai fait l'upload. Comme tu le vois, je prend des precautions plus grande que les gens qui font des backport un peu bacle, et c'est normal que cela risque de poser des problemes par la suite. Pourquoi je détecte le bug grossier en 2mn et pas le DD ? Parce que je suis en stable et lui en sid... Parceque tu essaye de faire tourner en woody un package prevu pour sid, c'est tout. = un DD devrait travailler dans un chroot qu'il fait évoluer en fonction des paquets qu'il construit (et teste) et rien de plus. Cela permettra que _ses_ dépendances (manuelles) soient spécifiées au plus juste. Ça sera déjà un paquet
Re: Uploader dans stable (was: Re: knoppix ( limite hs !!! ))
On Mon, Jun 23, 2003 at 10:53:07AM +0200, Georges Mariano wrote: On Mon, 23 Jun 2003 09:40:45 +0200 Sven Luther [EMAIL PROTECTED] wrote: Comprend pas, les dernieres versions de xfree86 devrait etre toutes aussi performante et pas forcement necessite plus de ressources que ^ Je ne veux pas de pas forcément lorsque je __sais__ que ce n'est pas nécessaire. Pas envie de réinstaller la machine si, manque de bol, ben si ça coince !!... Et ça n'est absolument une consolation de se dire que maintenant on va pouvoir dire à Sven que ça marche effectivement pas... xfree 3. Sur, j'ai pas essayer, mais j'ai l'intention d'installer X 4.3 sur mon portable 486 avec 300Mo de disque et 12Mo de ram. Donc, si tu a du detail pour l'asphyxie en question, ce serait sympa de le partager. Si tu trouves normal de vouloir mettre X4.3 sur ce genre de machine, amuse toi bien ;-) [à la louche, tu perds déjà min 30Mo de disque entre 3.3.6 et 4.1] Je suis pas sur, il suffit que je supprime a la mains tout les drivers pas necessaire, il est meme possible que je doive recompiler X moi meme, et que je supprime des chose comme l'AA et autre. Apres tout l'espace disque requis pour debian aveec X est d'au moins 800Mo, du mois c'est ce qui est dis sur le cite web. Ben asphyxie sur tous les points : disque / ram /cpu Ca c'est du bla bla. Est-ce que tu a quelque chose de plus specifique a nous donner ? Est-ce que tu sait que 4.3 utilise plus de ressources que 3.x, ou c'est juste de la desinformation ? Alors que le portable fonctionne nickel en 3.3.6 et qu'il est pas prévu d'en faire un client Quake !! S'il fonctionne nickel, alors ou est le probleme ? Non, bien sur, beaucoup de gens dans ce cas font comme toi, et n'upgrade pas. Non non, c'est __bien plus grave__, il ne s'agissait pas de moi mais d'un ami a qui j'avais dit tu verras Linux ça tourne bien sur une petite config et en plus avec la nouvelle Debian t'es blindé ... Ben non :-(( [Je crois que j'ai backporté sur une autre machine et transféré, c'est à dire que j'ai fais le boulot que naïvement je pensais être l'apanage de Debian.] Non, le backport n'est pas quelque chose qu'on s'est engage a faire, certains le font, mais c'est un plus. Non, bien sur, mais en fait je doute qu'il s'agisse reellement d'un probleme, et si s'en est un, alors il faut soumettre un bugreport contre X. tu rigole ?? Il y avait deux version de X disponibles la 3.3.6 et la 4.0. Il y avait deux manière de régler facilement le problème de pas mal de dépendance (je simplifie) soit 3.3.6 provides 4.0, et ça marchait bien sauf pour quelques applis pointues et là fallait passer en (vrai) 4.0 : _uniquement si nécessaire_ soit 4.0 provides 3.3.6 et là, de toute manière tu passes en 4.0 même si t'as pas besoin Ca c'est des connerie, excuse moi, mais tu est vraiment butter. La meilleure maniere c'est de garder le serveur X 3.3.6, vu que c'est celui la que tu pense marche le mieux, et d'installer les bibliotheques X 4.x, celle qui satisfont les dependances dont tu a besoin. Et je doute tres fort qu'il y ai un quelconque changement de ressource entre les bibliotheques, Xlibs 3.x et les 4.x. Le serveur je ne dis pas, et encore je ne suis pas sur que ce soit le cas, mais les biblliotheques, vraiment, elle ne devrait pas utiliser plus de ressources. Amicalement, Sven Luther
Re: Uploader dans stable (was: Re: knoppix ( limite hs !!! ))
Le Mon 23/06/2003, Sven Luther disait Ils ont qu'a attendre que la prochaine release sorte avec les nouvelles versions si ils ne peuvent pas se permettre de faire les mise a jour des dependances. Tu veut voir une copie de ma facture wanadoo de lorsque j'avait pas encore l'ADSL et de tout ce que j'ai payer pour uploader des packages a debian ? Et des gros packages en plus. Est-ce que je suis venu pleurer pour cela ? C'ets bien ce qu'on dit depuis un moment : certaines catégories d'utilisateurs n'intéressent pas les mainteneurs debian, qui les considèrenet comme négligeables. Venir parler de contrat social après est quand même la marque d'un certain culot. -- Erwan
Re: Uploader dans stable (was: Re: knoppix ( limite hs !!! ))
On Mon, Jun 23, 2003 at 01:23:31PM +0200, Erwan David wrote: Le Mon 23/06/2003, Sven Luther disait Ils ont qu'a attendre que la prochaine release sorte avec les nouvelles versions si ils ne peuvent pas se permettre de faire les mise a jour des dependances. Tu veut voir une copie de ma facture wanadoo de lorsque j'avait pas encore l'ADSL et de tout ce que j'ai payer pour uploader des packages a debian ? Et des gros packages en plus. Est-ce que je suis venu pleurer pour cela ? C'ets bien ce qu'on dit depuis un moment : certaines catégories d'utilisateurs n'intéressent pas les mainteneurs debian, qui les considèrenet comme négligeables. Attend, ou est le probleme ? C'est pas certaines categories d'utilisateurs qui n'interessent pas les developpeurs debian, c'est juste que lorsque l'on a des ressources limites, il faut affecter des priorites aux differents buts et s'y tenir pour pouvoir avancer. Et je supppose que par categorie tu dis ceux qui ne veulent pas utiliser unstable, et ne sont pas satisfait avec stable, pour une raison ou une autre. Est-ce exacte ? Pourquoi ne sont-il pas satisfait de stable ? C'est la version releaser officielle, et la seule chose que debian est capable de distribuer de maniere stable en ce moment. Venir parler de contrat social après est quand même la marque d'un certain culot. Tu parle du point 4 : 4 Nos priorités sont nos utilisateurs et les logiciels libres Les besoins de nos utilisateurs et de la communauté des logiciels libres nous guideront. Nous placerons leurs intérêts en tête de nos priorités. Nous assumerons les besoins opérationnels de nos utilisateurs dans de nombreux types d'environnements informatiques différents. Nous ne nous opposerons pas aux logiciels commerciaux prévus pour fonctionner sur les systèmes Debian, et nous permettrons que d'autres créent des distributions à valeur ajoutée contenant conjointement des logiciels Debian et des logiciels commerciaux, et ceci sans réclamer aucune rétribution. Pour assumer ces objectifs, nous fournirons un système intégré de haute qualité, composé en totalité de logiciels libres, sans restrictions légales qui empêcheraient ce type d'usage. Je crois que ce point parle uniquement des logiciels commerciaux, mais comme dis, rien n'empeche une tierce partie de faire des backport de qualite, et de les distribuer. Le seul probleme, c'est lorsque les backport sont mal fait, et que l'on voit apparaitre des bugreport dans le BTS qui ne corresponde pas aux package debian, alors cela coince. Mais a nouveau, rien ne t'empeche toi et Mariano de travailler sur des backports propres, et meme de devenir DD dans le but explicite de maintenir une distribution de backports, mais cela ne vous interesse pas. Amicalement, Sven Luther
Re: Uploader dans stable (was: Re: knoppix ( limite hs !!! ))
Le Mon 23/06/2003, Sven Luther disait Mais a nouveau, rien ne t'empeche toi et Mariano de travailler sur des backports propres, et meme de devenir DD dans le but explicite de maintenir une distribution de backports, mais cela ne vous interesse pas. Ça m'intéresserait peut-être n'étaient certains intégristes. Pour moi debian ce sera bientôt uniquement au boulot et encore tant que j'aurai la possibilité d'en virer un certain nombre de choses. Chez moi je passe à FreeBSD dès que hpoj peut y être compilé (et c'est pas le packaging debian qui va faire que le configure marche ailleurs que sous linux). -- Erwan
Re: Uploader dans stable (was: Re: knoppix ( limite hs !!! ))
On Mon, Jun 23, 2003 at 02:26:41PM +0200, Erwan David wrote: Le Mon 23/06/2003, Sven Luther disait Mais a nouveau, rien ne t'empeche toi et Mariano de travailler sur des backports propres, et meme de devenir DD dans le but explicite de maintenir une distribution de backports, mais cela ne vous interesse pas. Ça m'intéresserait peut-être n'étaient certains intégristes. Pour moi debian ce sera bientôt uniquement au boulot et Que d'excuse, ... encore tant que j'aurai la possibilité d'en virer un certain nombre de choses. Chez moi je passe à FreeBSD dès que hpoj peut y être compilé Tres bien pour toi alors. (et c'est pas le packaging debian qui va faire que le configure marche ailleurs que sous linux). J'imagine que les bugreport FTBFS de debian/netbsd et autre devrait quand meme aider. Amicalement, Sven Luther
Re: Uploader dans stable (was: Re: knoppix ( limite hs !!! ))
On Mon, Jun 23, 2003 at 01:58:02PM +0200, Sven Luther wrote: Et je supppose que par categorie tu dis ceux qui ne veulent pas utiliser unstable, et ne sont pas satisfait avec stable, pour une raison ou une autre. Est-ce exacte ? Pourquoi ne sont-il pas satisfait de stable ? C'est la version releaser officielle, et la seule chose que debian est capable de distribuer de maniere stable en ce moment. A un moment dans le thread, quelqu'un faisait remarquer que seuls les DD avaient voie au chapitre pour faire des décisions stratégiques, ce qui est un problème quand on veut s'adresser aux utilisateurs... Donc, pour résumer la situation: - Erwan, Georges, et d'autres, pensent que tout paquet devrait être compilé pour les dépendances les plus vieilles possibles. Si Perl 5.6.0 peut techniquement tourner sur Bo, le paquet ne devrait dépendre que de Bo. Si Hevea 3.6 a besoin de Ocaml 3.6, bien sûr il faudra upgrader Ocaml. Ceci permettrait d'avoir une distrib stable moins dépassée, où les nouvelles versions entreraient plus rapidement. En fait, la notion même de stable devient floue, puisque les versions des paquets pourraient y changer. (Il me semble que c'est plus ou moins le modèle adopté par Gentoo... mais je ne connais pas suffisament). - La position officielle de Debian (que j'ai finalement réussi à comprendre, merci Sven) est que les DD travaillent à la pointe, on remet tout à jour constament, et un jour on converge pour tout stabiliser et fixer les versions qu'on utilise. Du coup, tous les DD ont utilisé la nouvelle libc, le nouveau gcc, etc, et donc l'ensemble est plus testé (avantage par rapport à la méthode précédente). Un fois tout ça fixé, on vérifie que le passage stable-testing marche correctement (et on ne vérifie pas ça avant, si j'ai tout compris) et on fait une nouvelle stable. stable est donc plus testé, mais reste alors fixée pour les x années de developpement de la prochaine version. A priori et à mon avis, les deux positions se tiennent. Par contre: 4 Nos priorités sont nos utilisateurs et les logiciels libres Les besoins de nos utilisateurs et de la communauté des logiciels libres nous guideront. Nous placerons leurs intérêts en tête de nos priorités. Quel est le vrai interêt des utilisateurs? Car pour le moment, il semble que les utilisateurs (Erwan et Georges, et moi aussi un peu) ne sont en fait pas d'accord avec la façon dont Debian développe. Dans un environement de logiciel libre, où tous les composants évoluent indépendemment de Debian, est-il raisonnable pour Debian de vouloir faire des releases au même sens que les distributeurs commerciaux (RedHat ou Microsoft)? Et, quels utilisateurs ont été interrogés pour arriver à la conclusion qu'il fallait des releases bien définie, ou bien ce choix fut-il fait par les DD pour le bien des utilisateurs? Je crois que ce point parle uniquement des logiciels commerciaux, mais comme dis, rien n'empeche une tierce partie de faire des backport de qualite, et de les distribuer. Le seul probleme, c'est lorsque les backport sont mal fait, et que l'on voit apparaitre des bugreport dans le BTS qui ne corresponde pas aux package debian, alors cela coince. C'est clair, le BTS ne devrait être utilisé que pour les paquets officiels. Mais a nouveau, rien ne t'empeche toi et Mariano de travailler sur des backports propres, et meme de devenir DD dans le but explicite de maintenir une distribution de backports, mais cela ne vous interesse pas. Or donc, c'est bien là l'argument de Georges: les DD ne passent-ils pas leur temps à faire qqch que les utilisateurs ne veulent finalement pas vraiment, et ne serait il pas mieux passé à travailler différement (avec les mêmes ressources... et en changeant les buts). /Y - poseur de questions. -- Marbles should be kept together.
Re: Uploader dans stable (was: Re: knoppix ( limite hs !!! ))
Le Mon 23/06/2003, Sven Luther disait (et c'est pas le packaging debian qui va faire que le configure marche ailleurs que sous linux). J'imagine que les bugreport FTBFS de debian/netbsd et autre devrait quand meme aider. à aller chercher les libs dans /usr/local/lib au lieu de /usr/lib ? J'en doute... -- Erwan
Re: Uploader dans stable (was: Re: knoppix ( limite hs !!! ))
Le lundi 23 juin 2003, à 09:23, Georges Mariano écrivait : Je souhaite installer le paquet A.v1. J'installe, je lance le programme correspondant A, et boum ça plante. C'est du perl, j'ai un message sur le fichier fB, qui appartient au paquet B (que j'ai en version mettons v1...) Pourtant, je vais voir dans le paquet les dépendances sont satisfaites... A depends de B-v1. Alors ? Juste pour voir, apt-get install B -t sarge Je récupère la B-v2 Je relance A, ça marche!! Utilisateur docile : bugreport, Cher DD adoré, faut mettre une dépendance sur B.v2 et non pas B.v1. Voilà... On est content. Si c'est B.v1 qui se trouve dans ta version de la distribution et que B.v2 n'y est pas, il me semble franchement irresponsable de faire une dépendance vers B.v2. Mais dans ton idée, le paquet A.v1 lui-même ne fait pas exactement partie de cette version de la distribution, je me trompe ? Le DD a fait une 1ère version, il y a un certain temps avec une dépendance sur B.v1 (pour x raisons, ça marchait). Ensuite, comme tout DD qui se respecte, il suit la meute et upgrade régulièrement ça machine, tout évolue (paquet A et paquet B). Nouvelle version du paquet A construite dans le contexte sid comme il se doit mais avec B-v2 maintenant. Petit test de A. ok, ça marche. Paquet dans sid, personne ne voit rien tout les lemmings de cet acabit sont en sid ... ça arrive dans testing... j'installe chez moi et boum, ça plante. Durée du test : 2mn. Conclusion : les dépendances de A devraient être mises à jour pour coïncider avec le contexte sid du moment, le responsable du paquet ne vérifiant pas (et il n'a pas de raison de le faire) si la compatibilité est maintenue avec les anciennes versions, si bien que A ne passe en testing que lorsque B-v2 s'y trouve déjà. J'avais cru comprendre que c'était exactement ce que tu reprochais avec ton exemple de Xfree 4.1 (qui selon toi devrait être 3.x, voire sans mention de version). J'ai dû mal comprendre... Chacun est libre d'utiliser woody ou sarge ou sid mais pour faire un paquet, il vaut mieux se replacer dans le contexte stable pour détecter les dépendances minimales (c'est à dire plutôt celles qui sont en cours chez les utilisateurs... concept bien trop subtil pour un DD/sid j'en conviens). Pourquoi je détecte le bug grossier en 2mn et pas le DD ? Parce que je suis en stable et lui en sid... Quel bug ? Le but de Debian est de garantir la cohérence et l'intégrité au sein d'une version donnée de la distribution, pas de te permettre de sortir n'importe quel paquet et de faire en sorte qu'il s'acclimate par on ne sait quel miracle avec ta version de la distribution. Il me semble qu'on ne te promet ni plus ni moins, je n'en attends en tout cas pas plus (c'est déjà beaucoup), et selon mon expérience (certes partielle et limitée), cette promesse est largement tenue. = un DD devrait travailler dans un chroot qu'il fait évoluer en fonction des paquets qu'il construit (et teste) et rien de plus. Cela permettra que _ses_ dépendances (manuelles) soient spécifiées au plus juste. Ça sera déjà un paquet de bug en moins. Et comment se rend-il compte que B-v3, qui vient d'entrer en Sid, fait planter A, alors qu'il a gardé dans son chroot douillet B-v0.1 depuis Buzz ? C'est contradictoire avec ce que tu viens d'exposer. Par contre, construire dans stable, bof, mouai, ça manque d'adrénaline. Sauf que c'est le plus stable. Et c'est là l'essentiel de ma critique, on ne dit pas que l'on mets les besoins utilisateurs et la stabilité de la distrib sont prioritaires (et toutes les distributions disent la même chose ;-) quand on demande aux DD de bosser dans sid. Je suis peut-être passé à côté de plein de choses, mais dans mon idée, sid est précisément là pour que les DD y bossent : c'est là que se prépare la prochaine version de la distribution (via testing). Stable ne doit plus bouger hormis pour les mises-à-jour de sécurité. Ça n'aurait aucun sens de construire à partir de stable (comme tu l'as toi-même exposé dans ton premier exemple). Si tu souhaites y introduire des paquets plus récents, ça s'appelle du rétroportage et je crois savoir que tu ne t'en prives pas. On trouve d'ailleurs de plus en plus de paquets rétroportés. Forcément, ça implique (parfois) de mettre la main dans le cambouis, mais je ne vois rien de scandaleux à ça. Rien n'empêche de le faire ; simplement, Debian ne le fait pas à notre place. En tout cas, ça n'a pas à interférer avec la sortie de la prochaine distribution, amha. Ça, c'est une arnaque. On confond utilisateurs et mainteneurs. Je ne me sens pas du tout arnaqué. Je n'attends pas de Debian qu'elle fasse plus qu'elle ne prétend faire, à savoir me fournir un ensemble stable et cohérent de logiciels libres, accompagné de tout un tas d'outils d'administration et de configuration qui me facilitent considérablement la tâche. Et quand je dois l'adapter à mes besoins, je fais _mon_ boulot d'utilisateur. Je ne vais certainement pas lui
Re: Uploader dans stable (was: Re: knoppix ( limite hs !!! ))
On Mon, 23 Jun 2003 13:58:02 +0200 Sven Luther [EMAIL PROTECTED] wrote: Mais a nouveau, rien ne t'empeche toi et Mariano de travailler sur des backports propres, et meme de devenir DD dans le but explicite de maintenir une distribution de backports, mais cela ne vous interesse pas. Ce qui ne m'intéresse pas c'est, en faisant partie de Debian, de cautionner le double discours maintenant flagrant : le backport est une manip douteuse non supportée, etc etc, en dehors de Debian mais si c'est fait dans Debian alors ça devient une oeuvre d'utilité publique... Faudrait savoir, soit le backport est intéressant soit il ne l'est pas... Dans les deux cas, c'est la même technique. A+ -- debfr-faq: http://savannah.nongnu.org/download/debfr-faq/html/ val-linux: http://phalompe.homeip.net:9673/val-linux perso: http://www3.inrets.fr/estas/mariano
Re: Uploader dans stable (was: Re: knoppix ( limite hs !!! ))
On Mon, 23 Jun 2003 13:58:24 +0100 Yves Rutschle [EMAIL PROTECTED] wrote: utilise. Du coup, tous les DD ont utilisé la nouvelle libc, le nouveau gcc, etc, et donc l'ensemble est plus testé ?? comprends pas... comment tu peux tester plus une version libc6 toute neuve (quelques mois) par rapport a une version utilisée depuis plusieurs paquets de mois (années) ?? (avantage par rapport à la méthode précédente). Un fois tout ça fixé, on vérifie que le passage stable-testing marche correctement (et on ne vérifie pas ça avant, si j'ai tout compris) et comment fait-on cette vérification de passage (dynamique) puisque les forces vives (les DDs) sont en sid ? (ils réinstallent pour le plaisir ?) Dans un environement de logiciel libre, où tous les composants évoluent indépendemment de Debian, est-il raisonnable pour Debian de vouloir faire des releases au même sens que les distributeurs commerciaux (RedHat ou Microsoft)? Tout à fait d'accord, d'autant plus que le système est suffisamment puissant pour permettre une stabilité raisonnable en permanence... Mais ton message me fais penser à quelque chose ... a) l'existence même de www.apt-get.org est pour moi la preuve indéniable que Debian ne répond pas au besoin de ses utilisateurs. C'est l'institutionnalisation de la notion de sources non-officielles. La moindre des choses c'est d'analyser ce qui se passe ... b) ce constat amène la réflexion suivante que j'illustre par l'exemple de Xfree4.3 [pardonner les erreurs de numérotation, juste pour illustrer]. (Yves a raison ;-), après tout pourquoi Xfree4.3 devrait-elle nécessairement remplacer si vite la 4.1 officielle de woody ? _Personnellement_ (je répète, personnellement) j'ai plus de machine qui se contentent de Xfree4.1 que de Xfree4.3. Je suis donc plus intéressé par disposer en Debian/Centrale de xfree4.1 (bien stable) et optionnellement, sur une source externe, xfree4.3 pour LA machine dernier cri. c) allons même plus loin, la notion de Debian diffusée de manière centrale n'est elle pas en train de mourir pour être remplacée par la notion de «modules» systèmes, servis par des sources de qualité (souvent en people.debian.org) ayant des cycles distincts mais dont la cohésion est assurée par dpkg/apt ?? Houla, je crois qu'Yves vient de m'ouvrir (involontairement ;-) une porte sur des perspectives... fascinantes... A+ -- debfr-faq: http://savannah.nongnu.org/download/debfr-faq/html/ val-linux: http://phalompe.homeip.net:9673/val-linux perso: http://www3.inrets.fr/estas/mariano
Re: Uploader dans stable (was: Re: knoppix ( limite hs !!! ))
On Mon, Jun 23, 2003 at 01:58:24PM +0100, Yves Rutschle wrote: On Mon, Jun 23, 2003 at 01:58:02PM +0200, Sven Luther wrote: Et je supppose que par categorie tu dis ceux qui ne veulent pas utiliser unstable, et ne sont pas satisfait avec stable, pour une raison ou une autre. Est-ce exacte ? Pourquoi ne sont-il pas satisfait de stable ? C'est la version releaser officielle, et la seule chose que debian est capable de distribuer de maniere stable en ce moment. A un moment dans le thread, quelqu'un faisait remarquer que seuls les DD avaient voie au chapitre pour faire des décisions stratégiques, ce qui est un problème quand on veut s'adresser aux utilisateurs... Donc, pour résumer la situation: - Erwan, Georges, et d'autres, pensent que tout paquet devrait être compilé pour les dépendances les plus vieilles possibles. Si Perl 5.6.0 peut techniquement tourner sur Bo, le paquet ne devrait dépendre que de Bo. Si Hevea 3.6 a besoin de Ocaml 3.6, bien sûr il faudra upgrader Ocaml. Ceci permettrait d'avoir une distrib stable moins dépassée, où les nouvelles versions entreraient plus rapidement. En fait, la notion même de stable devient floue, puisque les versions des paquets pourraient y changer. (Il me semble que c'est plus ou moins le modèle adopté par Gentoo... mais je ne connais pas suffisament). C'est ce qu'aurrai du etre la distrib testing, elle l'est en partie, mais il y a encore des problemes, qui seront sans doutes resolu par la suite, apres la release de sarge. - La position officielle de Debian (que j'ai finalement réussi à comprendre, merci Sven) est que les DD travaillent à la pointe, on remet tout à jour constament, et un jour on converge pour tout stabiliser et fixer les versions qu'on utilise. Du coup, tous les DD ont utilisé la nouvelle libc, le nouveau gcc, etc, et donc l'ensemble est plus testé (avantage par rapport à la méthode précédente). Un fois tout ça fixé, on vérifie que le passage stable-testing marche correctement (et on ne vérifie pas ça avant, si j'ai tout Oui, c'est fait assez a la fin du cycle de release, le faire avant representerai une duplication d'effort non justifiable. compris) et on fait une nouvelle stable. stable est donc plus testé, mais reste alors fixée pour les x années de developpement de la prochaine version. Oui, il y a effectivement une divergence de but, et l'ideal serait d'obtenir les deux, et c'est probablement faissable, la divergence reelle est dans les moyens de l'obtenir, et dans l'ordre des priorites Moi, et c'est mon avis personnel, est que la meilleure solution serait de rapprocher les dates des releases debian, avec une release par ans, le probleme de stable qu n'est plus assez nouveau ne se posera plus alors. A priori et à mon avis, les deux positions se tiennent. Par contre: 4 Nos priorités sont nos utilisateurs et les logiciels libres Les besoins de nos utilisateurs et de la communauté des logiciels libres nous guideront. Nous placerons leurs intérêts en tête de nos priorités. Quel est le vrai interêt des utilisateurs? Car pour le moment, il semble que les utilisateurs (Erwan et Georges, et moi aussi un peu) ne sont en fait pas d'accord avec la façon dont Debian développe. Bon, il faut savoir que le chapitre en question etait surtout la pour donner un equilibre entre le besoin des utilisateur qui necessitait des logiciels commerciaux et le fait de n'accepter que des logiciels libres. C'est comme cela que je lis ce paragraphe, mais cela predate mon epoque, bien sur. Ceci dis, tu a bien raison, mais ce que Georges et Erwan propose c'est que les DDs ajoutent une charge de plus a leur implication dans debian, pour satisfaire un somme toute petit groupe d'utilisateur, qui se croient assez competent pour critiquer et juger de la meilleure maniere de faire pour debian, mais ne jugent pas cela assez important pour y devouer leur propre temps. D'un autre cote, il sont assez competent pour suivre soit testing soit unstable, mais ne le font pas. Moi, je sais de quel quantite de temps libre je dispose pour s'occuper de debian, et ce que je peut realiser avec cela, j'ai aussi un certain apercu de l'etat des choses, et donc je juge correct la politique de debian qui est de mettre la priorite a la prochaine release. C'est notre choix, et nous mettons toute notre energie pour l'accomplir. Maintenant, d'autre trouvent que ce n'est pas le bon choix, mais est-ce qu'il sont pret a donner d'eux meme pour soutenir leur choix, pas d'apres ce que je vois. Dans un environement de logiciel libre, où tous les composants évoluent indépendemment de Debian, est-il raisonnable pour Debian de vouloir faire des releases au même sens que les distributeurs commerciaux (RedHat ou Microsoft)? Oui, mais debian est aussi pour des utilisateurs de serveurs, et d'autre machine au cycle de release plus lent. C'est surtout a eux que s'adresse les mise a jour de securite d'ailleurs. Et c'est a eux que s'adressent
Re: Uploader dans stable (was: Re: knoppix ( limite hs !!! ))
On Mon, Jun 23, 2003 at 07:39:35PM +0200, Georges Mariano wrote: On Mon, 23 Jun 2003 13:58:24 +0100 Yves Rutschle [EMAIL PROTECTED] wrote: utilise. Du coup, tous les DD ont utilisé la nouvelle libc, le nouveau gcc, etc, et donc l'ensemble est plus testé ?? comprends pas... comment tu peux tester plus une version libc6 toute neuve (quelques mois) par rapport a une version utilisée depuis plusieurs paquets de mois (années) ?? (avantage par rapport à la méthode précédente). Un fois tout ça fixé, on vérifie que le passage stable-testing marche correctement (et on ne vérifie pas ça avant, si j'ai tout compris) et comment fait-on cette vérification de passage (dynamique) puisque les forces vives (les DDs) sont en sid ? (ils réinstallent pour le plaisir ?) Dans un environement de logiciel libre, où tous les composants évoluent indépendemment de Debian, est-il raisonnable pour Debian de vouloir faire des releases au même sens que les distributeurs commerciaux (RedHat ou Microsoft)? Tout à fait d'accord, d'autant plus que le système est suffisamment puissant pour permettre une stabilité raisonnable en permanence... Mais ton message me fais penser à quelque chose ... a) l'existence même de www.apt-get.org est pour moi la preuve indéniable que Debian ne répond pas au besoin de ses utilisateurs. C'est l'institutionnalisation de la notion de sources non-officielles. La moindre des choses c'est d'analyser ce qui se passe ... b) ce constat amène la réflexion suivante que j'illustre par l'exemple de Xfree4.3 [pardonner les erreurs de numérotation, juste pour illustrer]. (Yves a raison ;-), après tout pourquoi Xfree4.3 devrait-elle nécessairement remplacer si vite la 4.1 officielle de woody Vite ? Tu veut rire, oui, je parie que XFree86 fera une nouvelle release (4.4.0) avant que Debian n'aie de packages XFree86 4.3.0 dans sid. Un pari que je serait heureux de predre d'ailleurs. ? _Personnellement_ (je répète, personnellement) j'ai plus de machine qui se contentent de Xfree4.1 que de Xfree4.3. Je suis donc plus intéressé par disposer en Debian/Centrale de xfree4.1 (bien stable) et Et c'est pourquoi tu install woody sur tes machines, non ? Amicalement, Sven Luther
Re: Uploader dans stable (was: Re: knoppix ( limite hs !!! ))
* Georges Mariano [EMAIL PROTECTED] [2003-06-23 19:39] : [...] c) allons même plus loin, la notion de Debian diffusée de manière centrale n'est elle pas en train de mourir pour être remplacée par la notion de «modules» systèmes, servis par des sources de qualité (souvent en people.debian.org) ayant des cycles distincts mais dont la cohésion est assurée par dpkg/apt ?? Houla, je crois qu'Yves vient de m'ouvrir (involontairement ;-) une porte sur des perspectives... fascinantes... Certaines de ces idées ont déjà été évoquées sur la liste debian-devel (avec également d'autres idées proches de ce dont tu parles) : http://lists.debian.org/debian-devel/2003/debian-devel-200302/msg01801.html http://lists.debian.org/debian-devel/2003/debian-devel-200302/msg01832.html (retrouvés par la DWN du 4 mars 2003). J'avoue par contre que la lecture du fil entier n'est guère plus digeste que celle du fil actuel. Fred -- LA FAQ d-u-f ? http://savannah.nongnu.org/download/debfr-faq/html/
Re: Uploader dans stable (was: Re: knoppix ( limite hs !!! ))
On Mon, Jun 23, 2003 at 10:44:13AM +0200, Thomas Nemeth wrote: Le 22.06.03, Denis Barbier a tapoté : | Oui, mais je n'ai pas de chance, tu as cité la moitié du paragraphe où je | pose la question, ce qui le rend inintelligible, et tu n'y réponds même pas. | Le revoici donc en intégralité : | Prenons un exemple : hevea. Suivant ton raisonnement, il sera compilé avec | ocaml 3.04 (version dans stable). En parallèle, ocaml est aussi mis à jour, | en 3.06. Mais manque de bol, cet hevea refusera de tourner avec cet ocaml, | c'est pourquoi il y a une dépendance sur la version d'ocaml utilisée. | Comment faire alors pour qu'ocaml 3.06 rentre dans la prochaine version | stable, sans casser hevea ? Où est cette « continuité douce » promise ? Faut remettre à jour hevea après upgrade d'ocaml... Sauf que quand ocaml est upgradé, l'hevea dans cet espèce de stable est cassé ; si pour une raison quelconque il ne compile pas avec ocaml 3.06, il va rester cassé pour un bout de temps. Comme « continuité douce », on peut rêver mieux. Pour que les choses soient claires, la façon dont les paquets entrent dans la distribution testing est expliquée sur http://www.debian.org/devel/testing Avec le même exemple d'hevea, on voit qu'il est possible de mettre à jour ocaml et hevea sans que les paquets dans testing ne soient cassés, s'ils sont déplacés simultanément. J'aimerai avoir des explications similaires dans le cas où la compilation se fait sur la base de stable. Ou alors on admet que les paquets puissent être cassés pendant un laps de temps ? Denis
Re: Uploader dans stable (was: Re: knoppix ( limite hs !!! ))
Le Mon 23/06/2003, Denis Barbier disait Pour que les choses soient claires, la façon dont les paquets entrent dans la distribution testing est expliquée sur http://www.debian.org/devel/testing Avec le même exemple d'hevea, on voit qu'il est possible de mettre à jour ocaml et hevea sans que les paquets dans testing ne soient cassés, s'ils sont déplacés simultanément. J'aimerai avoir des explications similaires dans le cas où la compilation se fait sur la base de stable. Ou alors on admet que les paquets puissent être cassés pendant un laps de temps ? tu expliqueras donc pourquoi perlmagick est cassé dans testing celui en perl 5.8 ne pouvant être descendu à cause d'une dépendance sur lcms lui même bloqué parcequ'il dépend de libc6 2.3... -- Erwan
Re: Uploader dans stable (was: Re: knoppix ( limite hs !!! ))
On Mon, Jun 23, 2003 at 03:37:24PM +0200, Laurent Defours wrote: Le lundi 23 juin 2003, à 09:23, Georges Mariano écrivait : Je souhaite installer le paquet A.v1. J'installe, je lance le programme correspondant A, et boum ça plante. C'est du perl, j'ai un message sur le fichier fB, qui appartient au paquet B (que j'ai en version mettons v1...) Pourtant, je vais voir dans le paquet les dépendances sont satisfaites... A depends de B-v1. Alors ? Juste pour voir, apt-get install B -t sarge Je récupère la B-v2 Je relance A, ça marche!! Utilisateur docile : bugreport, Cher DD adoré, faut mettre une dépendance sur B.v2 et non pas B.v1. Voilà... On est content. Si c'est B.v1 qui se trouve dans ta version de la distribution et que B.v2 n'y est pas, il me semble franchement irresponsable de faire une dépendance vers B.v2. Mais dans ton idée, le paquet A.v1 lui-même ne fait pas exactement partie de cette version de la distribution, je me trompe ? Oui, mais les explications étaient tellement peu claires que ce n'est pas étonnant. Voici un autre exemple qui en reprend (je crois) l'idée. Les informations du paquet Debian perl 5.8 contiennent : Replaces: perl-5.005 ( 6), perl-5.6 ( 6), perl-doc ( 5.8.0-1), libdigest-md5-perl, libmime-base64-perl, libtime-hires-perl Provides: perl5, libdigest-md5-perl, libmime-base64-perl, libtime-hires-perl Conflicts: perl-5.004 ( 6), perl-5.005 ( 6), perl-5.6 ( 6), perl-doc ( 5.8.0-1), libdigest-md5-perl ( 2.20-1), libmime-base64-perl ( 2.12-1), libtime-hires-perl ( 1.20-1) Cela signifie que les modules (au sens Perl du terme) Digest::MD5, Mime::Base64 et Time::Hires font maintenant partie du paquet perl, et ne sont plus mis dans des paquets séparés. Un développeur veut mettre un nouveau paquet dans Debian, qui contient un script utilisant un de cas modules (si le paquet existait avant woody, il déclarait ces dépendances et le développeur n'aura pas l'idée de les enlever). Il met une dépendance sur perl sans se rendre compte que cette dépendance ne sera pas suffisante si on installe sur stable ou testing. Et comme le paquet ne déclare pas une dépendance sur perl = 5.8, il peut rentrer dans testing alors que perl 5.6 y est toujours. Sauf si on est un génie en expert logiciel, on comprend aisément que c'est symétrique : si le développeur teste dans stable, rien ne garantit que ça marchera à 100% dans unstable ou testing. Les utilisateurs en UTF-8 en savent peut-être quelque chose. Le problème est donc réel, mais la solution proposée n'en est pas une. Denis
Re: Uploader dans stable (was: Re: knoppix ( limite hs !!! ))
On Mon, 23 Jun 2003 20:28:11 +0200 Sven Luther [EMAIL PROTECTED] wrote: Vite ? Tu veut rire, oui, oui, c'était pour forcer le trait ... je parie que XFree86 fera une nouvelle release (4.4.0) avant que Debian n'aie de packages XFree86 4.3.0 dans sid. Un pari que je serait heureux de predre d'ailleurs. Tu crois pas si bien dire. Mon bateau a bien coulé. Il a suffit que je redémarre mon portable (avec xfree4.3 récupéré involontairement) pour que je constate que mon serveur X ne démarre pas vraiment... j'ai donc downgradé (technique du apt-cache policy + install version choisie) vers 4.2. J'ai fais une étape intermédiaire ... qui n'a pas durée (ça freeze aléatoirement). Je suis maintenant revenu en 4.1 et j'espère bien que sarge ne m'obligera pas a en sortir ;-) Et c'est pourquoi tu install woody sur tes machines, non ? Franchement non, les machines tournaient correctement en 3.3.6. Mais comme je suis passé en xfree4.0 à cause des «sur-dépendances» ben effectivement au bout d'un moment on passe en woody. Un peu comme un windowsien qui s'accroche à son win95 qui marche bien mais qui fini par passer à win98 par la force des choses et pas vraiment parce qu'il le souhaite. A+ -- debfr-faq: http://savannah.nongnu.org/download/debfr-faq/html/ val-linux: http://phalompe.homeip.net:9673/val-linux perso: http://www3.inrets.fr/estas/mariano
Re: Uploader dans stable (was: Re: knoppix ( limite hs !!! ))
On Mon, 23 Jun 2003 21:03:51 +0200 Frédéric Bothamy [EMAIL PROTECTED] wrote: * Georges Mariano [EMAIL PROTECTED] [2003-06-23 19:39] : Certaines de ces idées ont déjà été évoquées sur la liste debian-devel (avec également d'autres idées proches de ce dont tu parles) : http://lists.debian.org/debian-devel/2003/debian-devel-200302/msg01801.html http://lists.debian.org/debian-devel/2003/debian-devel-200302/msg01832.html ah ben tiens, j'ai raté ça ... comme quoi ... (retrouvés par la DWN du 4 mars 2003). J'avoue par contre que la lecture du fil entier n'est guère plus digeste que celle du fil actuel. ah ben oui, sans doute. Mais ce genre de sujet ne tiens pas en 5 lignes... c'est vrai. Aller, pour la route, le genre de remarques typiques : Proposal: Make all the people who talk but aren't going to do anything shut up. y'a pas, ça motive. ;-) A+ -- debfr-faq: http://savannah.nongnu.org/download/debfr-faq/html/ val-linux: http://phalompe.homeip.net:9673/val-linux perso: http://www3.inrets.fr/estas/mariano
