CPU ou core ?
Si c'est core et pour des quadri-cores on tombe à 40 machines (ce qui reste impressionnant).
> 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.
Mouaif... $ $ rpm -q --changelog -p kbde-1.1.6-9.36.src.rpm
attention: kbde-1.1.6-9.36.src.rpm: Entête V3 DSA signature: NOKEY, key ID 76edc1ff
* lun mai 14 2007 <valery_reznic@users.sourceforge.net> 1.1.5-1
- no real change - just to match kbde-driver version
Le dernier log n'est pas à jour (1.1.5-1 alors que le paquet est 1.1.6-9.36).
Le src.rpm a été reconstruit le 8 mars. $ rpm -q -i -p kbde-1.1.6-9.36.src.rpm | grep "Build Date"
attention: kbde-1.1.6-9.36.src.rpm: Entête V3 DSA signature: NOKEY, key ID 76edc1ff
Release : 9.36 Build Date: sam 08 mar 2008 07:54:34 CET
> 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.
Ce qui ne montre rien. Pour koji et probablement comme pour OpenSuSE, les requêtes de construction de paquet sont empilés dans une file. Ce n'est pas excécuté de suite.
> Aussi, la Factory est recompilée (quasi) entièrement une à deux fois par semaine
J'y crois pas. Mais si je me trompe, tant mieux.
> 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..
C'est une nécessité que le système de build gère les dépendances _lors_ de la construction.
Exemple pour mock (compilation de galeon). Mock est utilisé par koji (Fedora) :
$ mock --rebuild --root=fedora-8-x86_64 .../SRPMS/galeon-2.0.4-1.fc8.2.src.rpm : Installing:
gcc-c++ x86_64 4.1.2-33 fedora 3.7 M
make x86_64 1:3.81-10.fc8 fedora 482 k
redhat-rpm-config noarch 9.0.1-1.fc8 fedora 52 k
rpm-build x86_64 4.4.2.2-7.fc8 updates-released 303 k
tar x86_64 2:1.17-7.fc8 updates-released 911 k
unzip x86_64 5.52-6.fc8 updates-released 152 k
Installing for dependencies:
ConsoleKit-libs x86_64 0.2.3-3.fc8.1 updates-released 14 k
MAKEDEV x86_64 3.23-1.2 fedora 135 k
...
Transaction Summary
=============================================================================
Install 98 Package(s)
Update 0 Package(s)
Remove 0 Package(s)
Total download size: 95 M
Ceci est l'installation du minimum.
Puis mock installe ce qui est spécifique pour la construction de galeon : =============================================================================
DEBUG util.py:250: Package Arch Version Repository Size
=============================================================================
Installing:
ccache x86_64 2.4-11.fc8 fedora 53 k
firefox-devel x86_64 2.0.0.12-1.fc8 updates-released 3.5 M
gettext x86_64 0.16.1-12.fc8 fedora 1.5 M
gnome-desktop-devel x86_64 2.20.3-1.fc8 updates-released 38 k
intltool x86_64 0.36.2-1.fc8 fedora 89 k
Installing for dependencies:
ConsoleKit x86_64 0.2.3-3.fc8.1 updates-released 56 k
GConf2 x86_64 2.20.1-1.fc8 fedora 1.6 M
...
Transaction Summary
=============================================================================
Install 202 Package(s)
Update 0 Package(s)
Remove 0 Package(s)
Total download size: 115 M
Rien que pour construire Galeon, il y a 300 (!) dépendances !!! Soyons gentil et disons qu'on trouve ses 300 dépendances dans 100 paquets src.rpm.
Tu nous expliques que Galeon va être recompiler dès qu'un de ses 100 paquets est recompilé. Ceci est pour moi de la "foutaise".
Enfin, il y a les problèmes de dépendance cyclique et j'aimerai bien savoir comment fait OpenSuSE pour gérer ça...
Et que ce passe-t-il si une mauvaise version de libc est introduite ?
Tout est recompilé, tout échoue, et tout est cassé.
> 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
Et non Fedora ne recompile pas tout dans ce cas.
*Parfois* Fedora fait des recompilations de tous les paquets (typiquement lors d'un changement majeur de version de compilo, etc). Quand ça arrive, ça devient un projet à lui seul tellement c'est lourd à gérer (beaucoup de paquet plante à la compilation, etc).
En passant, la compilation d'OOo chez Fedora (i386/x86_64/ppc/ppc64) prend 8 heures ! Nombre de dépendance 387 !
Si à chaque changement d'une dépendance il faut recompiler OOo, ben tu le recompiles tous les 2 jours au minimum
Mais il y a "pire", c'est la bande passante. Les utilisateurs (mirroirs compris) ne vont absolument pas aprécier d'avoir à downloader des centaines de Mo car un paquet a été mis à jour.
Fedora ne recompile pas systématiquement et c'est déjà vraiment, vraiment limite (pas seulement pour Fedora, mais pour les mirroirs et les utilisateurs). Donc je ne crois pas qu'OpenSuSE recompile tout si une dépendance change. Ou alors OpenSuse est sur une autre planète et ce n'est pas la mienne.
[^] # Re: Re:
Posté par IsNotGood . En réponse au journal Diverses choses sur les packages managers. Évalué à 2.
CPU ou core ?
Si c'est core et pour des quadri-cores on tombe à 40 machines (ce qui reste impressionnant).
> 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.
Mouaif...
$ $ rpm -q --changelog -p kbde-1.1.6-9.36.src.rpm
attention: kbde-1.1.6-9.36.src.rpm: Entête V3 DSA signature: NOKEY, key ID 76edc1ff
* lun mai 14 2007 <valery_reznic@users.sourceforge.net> 1.1.5-1
- no real change - just to match kbde-driver version
Le dernier log n'est pas à jour (1.1.5-1 alors que le paquet est 1.1.6-9.36).
Le src.rpm a été reconstruit le 8 mars.
$ rpm -q -i -p kbde-1.1.6-9.36.src.rpm | grep "Build Date"
attention: kbde-1.1.6-9.36.src.rpm: Entête V3 DSA signature: NOKEY, key ID 76edc1ff
Release : 9.36 Build Date: sam 08 mar 2008 07:54:34 CET
> 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.
Ce qui ne montre rien. Pour koji et probablement comme pour OpenSuSE, les requêtes de construction de paquet sont empilés dans une file. Ce n'est pas excécuté de suite.
> Aussi, la Factory est recompilée (quasi) entièrement une à deux fois par semaine
J'y crois pas. Mais si je me trompe, tant mieux.
> 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..
C'est une nécessité que le système de build gère les dépendances _lors_ de la construction.
Exemple pour mock (compilation de galeon). Mock est utilisé par koji (Fedora) :
$ mock --rebuild --root=fedora-8-x86_64 .../SRPMS/galeon-2.0.4-1.fc8.2.src.rpm
: Installing:
gcc-c++ x86_64 4.1.2-33 fedora 3.7 M
make x86_64 1:3.81-10.fc8 fedora 482 k
redhat-rpm-config noarch 9.0.1-1.fc8 fedora 52 k
rpm-build x86_64 4.4.2.2-7.fc8 updates-released 303 k
tar x86_64 2:1.17-7.fc8 updates-released 911 k
unzip x86_64 5.52-6.fc8 updates-released 152 k
Installing for dependencies:
ConsoleKit-libs x86_64 0.2.3-3.fc8.1 updates-released 14 k
MAKEDEV x86_64 3.23-1.2 fedora 135 k
...
Transaction Summary
=============================================================================
Install 98 Package(s)
Update 0 Package(s)
Remove 0 Package(s)
Total download size: 95 M
Ceci est l'installation du minimum.
Puis mock installe ce qui est spécifique pour la construction de galeon :
=============================================================================
DEBUG util.py:250: Package Arch Version Repository Size
=============================================================================
Installing:
ccache x86_64 2.4-11.fc8 fedora 53 k
firefox-devel x86_64 2.0.0.12-1.fc8 updates-released 3.5 M
gettext x86_64 0.16.1-12.fc8 fedora 1.5 M
gnome-desktop-devel x86_64 2.20.3-1.fc8 updates-released 38 k
intltool x86_64 0.36.2-1.fc8 fedora 89 k
Installing for dependencies:
ConsoleKit x86_64 0.2.3-3.fc8.1 updates-released 56 k
GConf2 x86_64 2.20.1-1.fc8 fedora 1.6 M
...
Transaction Summary
=============================================================================
Install 202 Package(s)
Update 0 Package(s)
Remove 0 Package(s)
Total download size: 115 M
Rien que pour construire Galeon, il y a 300 (!) dépendances !!! Soyons gentil et disons qu'on trouve ses 300 dépendances dans 100 paquets src.rpm.
Tu nous expliques que Galeon va être recompiler dès qu'un de ses 100 paquets est recompilé. Ceci est pour moi de la "foutaise".
Enfin, il y a les problèmes de dépendance cyclique et j'aimerai bien savoir comment fait OpenSuSE pour gérer ça...
Et que ce passe-t-il si une mauvaise version de libc est introduite ?
Tout est recompilé, tout échoue, et tout est cassé.
> 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
Changement gcc (une fois par semaine) :
http://koji.fedoraproject.org/koji/packageinfo?packageID=40
Changement glibc (une fois toutes les deux semaines) :
http://koji.fedoraproject.org/koji/packageinfo?packageID=57
Et non Fedora ne recompile pas tout dans ce cas.
*Parfois* Fedora fait des recompilations de tous les paquets (typiquement lors d'un changement majeur de version de compilo, etc). Quand ça arrive, ça devient un projet à lui seul tellement c'est lourd à gérer (beaucoup de paquet plante à la compilation, etc).
En passant, la compilation d'OOo chez Fedora (i386/x86_64/ppc/ppc64) prend 8 heures ! Nombre de dépendance 387 !
Si à chaque changement d'une dépendance il faut recompiler OOo, ben tu le recompiles tous les 2 jours au minimum
Mais il y a "pire", c'est la bande passante. Les utilisateurs (mirroirs compris) ne vont absolument pas aprécier d'avoir à downloader des centaines de Mo car un paquet a été mis à jour.
Fedora ne recompile pas systématiquement et c'est déjà vraiment, vraiment limite (pas seulement pour Fedora, mais pour les mirroirs et les utilisateurs). Donc je ne crois pas qu'OpenSuSE recompile tout si une dépendance change. Ou alors OpenSuse est sur une autre planète et ce n'est pas la mienne.