| 1 |
On Thu, 2006-07-27 at 16:23 +0200, Ivan Havlicek wrote: |
| 2 |
|
| 3 |
> Cela me semble une très bonne idée, cela permetterait un "taux |
| 4 |
> de recouvrement" (paquets bin avec mêmes USE) bien meilleur. |
| 5 |
> Je pense pouvoir modifier rapidement l'arborescence pour ajouter |
| 6 |
> une subdivision au niveau le plus haut : |
| 7 |
> grp/sansXorg/ |
| 8 |
> grp/avecXorg/ |
| 9 |
> (plutôt que server/desktop car j'ai des serveurs qui ont X11) |
| 10 |
> Je me demande s'il ne faudrait pas aussi différencier KDE et Gnome. |
| 11 |
> |
| 12 |
> Je suis aussi en train de préparer un système d'authentification qui |
| 13 |
> permette à ceux qui le désirent de contribuer en uploadant |
| 14 |
> les paquets qu'ils ont compilés sur leur machine (FEATURES="buildpkg") |
| 15 |
> -- |
| 16 |
> Ivan |
| 17 |
|
| 18 |
J'ai suivi le fil de la discussion en entier sans avoir le temps d'y |
| 19 |
répondre. |
| 20 |
Le principe de faire un serveur de packages binaires est excellent, j'y |
| 21 |
ai pensé à maintes reprises et je suis toujours resté sur le problème de |
| 22 |
recouvrement des USE flags utilisés. En effet, si on s'amuse à calculer |
| 23 |
la couverture du nombre de possiblité des packages avec toutes les |
| 24 |
combinaisons de USE flags, plus le nombre d'architectures différentes, |
| 25 |
cela revient rapidement à des nombres de compilation et des capacités de |
| 26 |
stockage impressionnants. Néanmoins une grosse architecture réseau avec |
| 27 |
utilisation massive de distcc pour la compilation et aggrégation de |
| 28 |
l'espace de stockage pourrait permettre d'y venir à bout. Je ne parle |
| 29 |
même pas des problèmes de bande passante que cela donnerait car un tel |
| 30 |
système serait massivement choisi par les utilisateurs je pense, |
| 31 |
notamment à l'installation où les temps de compilation sont importants |
| 32 |
et freine pour beaucoup l'utilisation de gentoo en tant que serveur. |
| 33 |
|
| 34 |
|
| 35 |
Donc, la problématique de pouvoir avoir tous les pkgs compilés avec |
| 36 |
toutes les combinaisons de USE flags pour avoir une couverture de 100% |
| 37 |
se résume en trois points: |
| 38 |
|
| 39 |
1) La puissance et le temps de compilation nécessaire. |
| 40 |
2) La capacité de stockage. |
| 41 |
3) La bande passante nécessaire. |
| 42 |
|
| 43 |
|
| 44 |
Et là j'ai une petite idée qui me trotte dans la tête depuis plus d'un |
| 45 |
an (je suis sur gentoo depuis la version 1.2): |
| 46 |
|
| 47 |
1) Le problème des temps de compilation peut être déporté sur les |
| 48 |
utilisateurs étant donné qu'à la base, gentoo fonctionne sur le principe |
| 49 |
que chacun compile pour ses besoins. |
| 50 |
2) et 3) La capacité de stockage et la bande passante peuvent être |
| 51 |
deportés d'une architecture centralisé sur une architecture P2P |
| 52 |
permettant de résoudre le problème de bande passante et de capacité de |
| 53 |
stockage d'un seul coup. |
| 54 |
|
| 55 |
En conclusion, ne serait il pas fortement intéressant de créer un |
| 56 |
serveur P2P (bittorent ? un serveur edonkey ?) auquel chaque utilisateur |
| 57 |
partagerait ses packages binaires, ce qui dans la pratique permettrait |
| 58 |
d'approcher une couverture maximale sans forcément atteindre la |
| 59 |
couverture totale... Le P2P faisant office par son fonctionnement même |
| 60 |
de système statistique pour les differentes architectures et combinaison |
| 61 |
de USE FLAGS. |
| 62 |
|
| 63 |
Bon dans la pratique ca semble jouable mais il reste un gros problème: |
| 64 |
le nommage des packages compilés car autant un package compilé |
| 65 |
différement (arch+use) aurait un hash différent ce qui permettrait de |
| 66 |
les différencier, rien ne pourrait les différencier par contre au niveau |
| 67 |
du nom, ce qui poserait un problème pour greffer un tel système à |
| 68 |
portage... Mais là n'ayant jamais pratiqué d'installation par packages |
| 69 |
binaires, je ne sais pas comment portage réagit pour faire la différence |
| 70 |
entre les architectures et les USE flags. |
| 71 |
|
| 72 |
Je suis curieux d'avoir votre avis la dessus, car je pense que la |
| 73 |
communauté entière gentoo aurait un intêret énorme à fonctionner sur un |
| 74 |
tel modèle... Economie d'energie à grande echelle, économie de bande |
| 75 |
passante et rapidité |
| 76 |
d'installation serait au rendez vous.... |
| 77 |
|
| 78 |
|
| 79 |
Voili voilou, en espérant ne pas avoir dis de grosses boulettes ! ;o) |
| 80 |
|
| 81 |
|
| 82 |
Zentoo |
| 83 |
|
| 84 |
|
| 85 |
-- |
| 86 |
-------------------------------------------------------------------------------------- |
| 87 |
Jean-François Maeyhieux |
| 88 |
-------------------------------------------------------------------------------------- |
| 89 |
PGP Public Key - Key ID = 63DB4770 Tuttle (JFM) <b4b1@××××.fr> |
| 90 |
http://pgpkeys.mit.edu:11371/pks/lookup?op=get&search=0x63DB4770 |
| 91 |
-------------------------------------------------------------------------------------- |
Archives