>>Toute l'infrastructure du Build Service tourne sur plus d'une centaine de machines généreusement données par AMD au projet openSUSE
>Et pourquoi pas des milliers !
>Pour Fedora (compilation i386, x86_64, ppc et ppc64), il n'y a "que" dix machines (certaines virtuelles) :
>http://koji.fedoraproject.org/koji/hosts
>Et tout y est compilé, ce n'est pas que dédié "extras". La distribution y est compilé, les mises à jours, les contributions externes, rawhide, etc.
Tu as raison, je suis allé un peu vite. De mémoire, il me semblait avoir lu quelque part le nombre de 126 machines (irc ?). Je n'ai pas réussi à retrouver une source pour ce nombre.
Cependant, sur le blog d'un développeur KDE employé par SuSE/Novell [1], j'ai trouvé le nombre de "plus de 120 CPUs" qui me laisse penser que ma mémoire était bonne,
Alors effectivement, ce n'est pas plus de 120 machines (du moins je pense, je n'ai aucune idée du nombre de CPU par machine, et encore moins du nombre de core par CPU...).
Ma seconde erreurs est d'avoir écrit tacitement que ces machines ont toutes été données par AMD. C'est bien sûr l'ensemble des machines (don AMD + le parc existant) qui représente ces 120+ CPUs.
>> Le Build Service a de multiples avantages :
>> - Il resoud automatiquement les dépendances des paquets compilés.
>Ce n'est pas un avantage, c'est une nécessité.
>> Ainsi, si un paquet B dépend d'un autre paquet A, le paquet B va être automatiquement recompilé si la dépendance A est modifiée et recompilée.
>"Foutaise".
>Presque tous les paquets dépendent de libc ou gcc. Si libc ou gcc est changé, tu nous expliques que le build système va recompiler tous les paquets !
>Et comment tu fais pour gérer les versions ? Ben oui, il va y avoir des toto-1.0-1 avec différent libc et gcc. Ça sucks.
>Bref, ce truc je n'y crois pas.
C'est pourtant ce qu'il se passe. Heureusement, la libc et gcc ne changent pas trop pour une version stable, mais il en est autrement pour les builds Factory (la version de dev opensuse).
Cet utilisateur lambda a compilé quelques paquets pour une version stable (10.3) et la version Factory. Je sais, de source sûre, que cet utilisateur a compilé ces paquets dans le mois d'octobre 2007 et n'y a pas touché depuis.
Les paquets du répertoire 10.3 sont datés d'octobre 2007. En revanche, les paquets Factory sont datés de deux jours (samedi 8 mars 2008 vers 07h55 - mes sources indiques que l'utilisateur lambda cité dormait encore), soit grosso modo la date de la dernière recompilation de la Factory. Et c'est comme ça pour tous les builds Factory.
Aussi, la Factory est recompilée (quasi) entièrement une à deux fois par semaine (à chaque mise à jour, et pas seulement lors du changement de la libc ou gcc). Ca permet de s'assurer que tous les paquets fonctionneront (avec le désavantage e lancer une compile après l'autre.. ).
J'imagine que les paquets compilés pour une version stable sont recompilés lors d'une mise à jour de sécurité (un rapide coup d'oeil à la liste des maj de sécu me montre qu'il n'y a pas eu d'update de la libc / gcc de octobre à ce jour). Ou alors, peut être qu'une simple faille corrigée dans la libc/gcc ne fait pas perdre de son caractère compatible (?).
Enfin, il me semble qu'entre la ligne du "c'est une nécessité" et la suivante "Foutaise" qui parle du même sujet, il y a une subtilité qui m'échappe..
>Mais il me semble qu'un aspect est "négligé". >C'est la qualité, une vue d'ensemble. Fedora ne permet pas à tout le monde de compiler sur koji pour des raisons de qualité. >Un paquet est accèpté qu'après un audit sérieux du paquet (licence, état de l'art, es-ce une technologie obsolète ou pas, etc).
>Ça s'inscrit dans un projet qui a des objectifs. Ça fédère dans gens autour de ces objectifs. Ce n'est pas une libre service. >C'est un mal et c'est un bien. Limiter les fonctionnalités (par exemple ne pas permettre à tout le monde de compiler) n'est pas forcément un mal.
Effectivement, je n'ai pas trop parlé de cet aspect "qualité". Après un rapide aperçu du BS, je voulais surtout mettre le doigt sur la possibilité de compiler des paquets autres qu'openSUSE (ce qui est surement plus intéressants pour la majorité des leceturs linuxfr), et surtout que la démarche entreprise par Fedora est la même pour les toutes autres distributions j'imagine.
Pour openSUSE, la seule différence est que les paquets "grands publics" (/repositories/home:/user) sont déjà dispo. Mais ils doivent bien sûr être approuvés avant d'entrer dans les dépôts semi-officiels contenus dans /repositories/projet (ex:KDE:/Backport) ou communautaires (ex: KDE:/Community).
Pour ceux que ça intéresse, cette présentation[2] fournit un schéma montrant bien le processus (slide 17). Le reste du PDF aborde les principes généraux du BS et quelques limites du BS dont je n'ai pas parlés. Egalement, le wiki openSUSE est assez exhaustif.
Pour smart, c'est justement le comportement que tu décris que je citais comme "efficacité agressive", mais je reprendrais ça ce week end (si j'ai le temps..)
[^] # Re: Re:
Posté par Spyhawk . En réponse au journal Diverses choses sur les packages managers. Évalué à 3.
>Et pourquoi pas des milliers !
>Pour Fedora (compilation i386, x86_64, ppc et ppc64), il n'y a "que" dix machines (certaines virtuelles) :
>http://koji.fedoraproject.org/koji/hosts
>Et tout y est compilé, ce n'est pas que dédié "extras". La distribution y est compilé, les mises à jours, les contributions externes, rawhide, etc.
Tu as raison, je suis allé un peu vite. De mémoire, il me semblait avoir lu quelque part le nombre de 126 machines (irc ?). Je n'ai pas réussi à retrouver une source pour ce nombre.
Cependant, sur le blog d'un développeur KDE employé par SuSE/Novell [1], j'ai trouvé le nombre de "plus de 120 CPUs" qui me laisse penser que ma mémoire était bonne,
Alors effectivement, ce n'est pas plus de 120 machines (du moins je pense, je n'ai aucune idée du nombre de CPU par machine, et encore moins du nombre de core par CPU...).
Ma seconde erreurs est d'avoir écrit tacitement que ces machines ont toutes été données par AMD. C'est bien sûr l'ensemble des machines (don AMD + le parc existant) qui représente ces 120+ CPUs.
>> Le Build Service a de multiples avantages :
>> - Il resoud automatiquement les dépendances des paquets compilés.
>Ce n'est pas un avantage, c'est une nécessité.
>> Ainsi, si un paquet B dépend d'un autre paquet A, le paquet B va être automatiquement recompilé si la dépendance A est modifiée et recompilée.
>"Foutaise".
>Presque tous les paquets dépendent de libc ou gcc. Si libc ou gcc est changé, tu nous expliques que le build système va recompiler tous les paquets !
>Et comment tu fais pour gérer les versions ? Ben oui, il va y avoir des toto-1.0-1 avec différent libc et gcc. Ça sucks.
>Bref, ce truc je n'y crois pas.
C'est pourtant ce qu'il se passe. Heureusement, la libc et gcc ne changent pas trop pour une version stable, mais il en est autrement pour les builds Factory (la version de dev opensuse).
Prenons un exemple : Je choisis totalement arbitrairement le dépôt personnel d'un utilisateur lambda : http://download.opensuse.org/repositories/home:/Spyhawk/.
Cet utilisateur lambda a compilé quelques paquets pour une version stable (10.3) et la version Factory. Je sais, de source sûre, que cet utilisateur a compilé ces paquets dans le mois d'octobre 2007 et n'y a pas touché depuis.
Les paquets du répertoire 10.3 sont datés d'octobre 2007. En revanche, les paquets Factory sont datés de deux jours (samedi 8 mars 2008 vers 07h55 - mes sources indiques que l'utilisateur lambda cité dormait encore), soit grosso modo la date de la dernière recompilation de la Factory. Et c'est comme ça pour tous les builds Factory.
Aussi, la Factory est recompilée (quasi) entièrement une à deux fois par semaine (à chaque mise à jour, et pas seulement lors du changement de la libc ou gcc). Ca permet de s'assurer que tous les paquets fonctionneront (avec le désavantage e lancer une compile après l'autre.. ).
J'imagine que les paquets compilés pour une version stable sont recompilés lors d'une mise à jour de sécurité (un rapide coup d'oeil à la liste des maj de sécu me montre qu'il n'y a pas eu d'update de la libc / gcc de octobre à ce jour). Ou alors, peut être qu'une simple faille corrigée dans la libc/gcc ne fait pas perdre de son caractère compatible (?).
Enfin, il me semble qu'entre la ligne du "c'est une nécessité" et la suivante "Foutaise" qui parle du même sujet, il y a une subtilité qui m'échappe..
>Mais il me semble qu'un aspect est "négligé". >C'est la qualité, une vue d'ensemble. Fedora ne permet pas à tout le monde de compiler sur koji pour des raisons de qualité. >Un paquet est accèpté qu'après un audit sérieux du paquet (licence, état de l'art, es-ce une technologie obsolète ou pas, etc).
>Ça s'inscrit dans un projet qui a des objectifs. Ça fédère dans gens autour de ces objectifs. Ce n'est pas une libre service. >C'est un mal et c'est un bien. Limiter les fonctionnalités (par exemple ne pas permettre à tout le monde de compiler) n'est pas forcément un mal.
Effectivement, je n'ai pas trop parlé de cet aspect "qualité". Après un rapide aperçu du BS, je voulais surtout mettre le doigt sur la possibilité de compiler des paquets autres qu'openSUSE (ce qui est surement plus intéressants pour la majorité des leceturs linuxfr), et surtout que la démarche entreprise par Fedora est la même pour les toutes autres distributions j'imagine.
Pour openSUSE, la seule différence est que les paquets "grands publics" (/repositories/home:/user) sont déjà dispo. Mais ils doivent bien sûr être approuvés avant d'entrer dans les dépôts semi-officiels contenus dans /repositories/projet (ex:KDE:/Backport) ou communautaires (ex: KDE:/Community).
Pour ceux que ça intéresse, cette présentation[2] fournit un schéma montrant bien le processus (slide 17). Le reste du PDF aborde les principes généraux du BS et quelques limites du BS dont je n'ai pas parlés. Egalement, le wiki openSUSE est assez exhaustif.
Pour smart, c'est justement le comportement que tu décris que je citais comme "efficacité agressive", mais je reprendrais ça ce week end (si j'ai le temps..)
[1] http://www.kdedevelopers.org/node/2850
[2] http://bw.uwcs.co.uk/talks/OBSTalk_WUGLUG.pdf