> Les bénéfices, pour une distribution grand public sont conséquent et je pense que cette pratique sera étendue à la plupart des distributions.
Je ne crois pas. Ça va surtout intéresser les kékés.
> 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.
> 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.
> En comparaison, un mirroir ubuntu entier (incluant ISO) pèse ~ 260Go, debian (sans ISO) pèse ~320Go
Pour info :
Le mirror Fedora sur fr2.rpmfind.net (rawhide, et "seulement" F7 et F8) : 480 Go.
> PackageKit n'est pas sponsorisé, mais le projet semble intéresser Red Hat, openSUSE
Le mainteneur est un développeur Red Hat il me semble.
Pour l'instant il n'est pas prévu que PackageKit remplace Pirut, etc. PackageKit sera fournit avec F9.
> te donne rendez vous pour le prochain, qui traitera de façon pas trop superficielle les algorithmes de résolution des dépendances, les limites actuelles et peut être quelques solutions prometteuses.
Merci pour le temps que tu consacres à faire ces bons articles.
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.
Pour les algorithmes de résolution, il y a des "astuces" qui semblent moins sucker. Mais au niveau rigueur, c'est plus douteux (par exemple smart qui downgrade un paquet pour en installer un autre).
Qui peut le plus plus peut le moins. Mais ce n'est pas forcément pour le meilleur.
# Re:
Posté par IsNotGood . En réponse au journal Diverses choses sur les packages managers. Évalué à 3.
Je ne crois pas. Ça va surtout intéresser les kékés.
> 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.
> 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.
> En comparaison, un mirroir ubuntu entier (incluant ISO) pèse ~ 260Go, debian (sans ISO) pèse ~320Go
Pour info :
Le mirror Fedora sur fr2.rpmfind.net (rawhide, et "seulement" F7 et F8) : 480 Go.
> PackageKit n'est pas sponsorisé, mais le projet semble intéresser Red Hat, openSUSE
Le mainteneur est un développeur Red Hat il me semble.
Pour l'instant il n'est pas prévu que PackageKit remplace Pirut, etc. PackageKit sera fournit avec F9.
> te donne rendez vous pour le prochain, qui traitera de façon pas trop superficielle les algorithmes de résolution des dépendances, les limites actuelles et peut être quelques solutions prometteuses.
Merci pour le temps que tu consacres à faire ces bons articles.
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.
Pour les algorithmes de résolution, il y a des "astuces" qui semblent moins sucker. Mais au niveau rigueur, c'est plus douteux (par exemple smart qui downgrade un paquet pour en installer un autre).
Qui peut le plus plus peut le moins. Mais ce n'est pas forcément pour le meilleur.