Lorsque l'on a plusieurs machines plus ou moins identiques, c'est dommage (et même une perte de temps et un gaspillage d'électricité) de devoir compiler encore et encore les mêmes programmes pour chacune des machines.
On peut aussi vouloir installer Gentoo sur une machine trop lente ou n'ayant pas suffisamment de ressources pour compiler quoi que ce soit.

Dans ces 2 cas, la solution est d'installer un serveur de packges pré-compilés.

On va choisir une machine avec un CPU relativement rapide et surtout avec assez de mémoire pour effectuer les compilations (dans mon cas, ça sera celeron) : ça sera notre binhost.

Les options de compilation de CFLAGS doivent être suffisamment génériques pour que les binaires fonctionnent sur toutes les machines cibles : dans mon cas, ça sera

CFLAGS="-O2 -march=i686 -pipe -fomit-frame-pointer"

Les binaires fonctionneront donc sur mes K7, Athlon, Celeron et P4 ... mais ni sur mes P1 ou 486 (ça sera pour plus tard).

Le choix des USEs est aussi important, car tous les programmes dont les USEs diffèrent entre le binhost et ses clients seront recompilés localement. Sont aussi concernés les fichiers /etc/make.conf et ceux contenus dans /etc/portage/*, ainsi que les variables telles que APACHE2_MODULES, VIDEO_CARDS, INPUT_DEVICES, CAMERAS ou LINGUAS.

Pour plus de sécurité, le repository de portage devra être synchronisé entre toutes les machines ... on installera donc un miroir local.

Certains USEs nécessitent une attention particulière, il s'agit des flags liés aux caractéristiques des CPU tels que sse, mmx, 3dnow. On peut carrément les omettre, alors les binaires ne seront pas optimisés, mais fonctionneront directement sur toutes les machines. Perso, ayant des machines très lentes, j'ai préféré activer ces USEs et recompiler localement certains packages.
Sur celeron, j'aurai donc

USE=' mmx sse sse2'.

Pour qu'emerge crée des packages binaires, il faut rajouter buildpkg dans FEATURES de /etc/make.conf.

quickpkg permettra de générer les binaires pour les packages déjà installés sur binhost. On peut aussi recompiler la totalité du système par un

emerge -ve @world

Sur les clients, on aura comme expliqué plus haut les mêmes USEs que sur le binhost, seuls les flags concernant le CPU sera changé en :

 USE="mmx 3dnow"

Dans /etc/make.conf, on aura

SYNC="rsync://celeron.chez.moi/gentoo-portage"

pour activer le miroir local de package.

PORTAGE_BINHOST="rsync://celeron.chez.moi/gentoo-distbin"
FEATURES="getbinpkg"

pour activer la fonction binhost. Et oui, contrairement à ce que j'ai trouvé dans beaucoup de doc, le protocole rsync fonctionne ici aussi. Cool, pas besoin d'installer un serveur ftp ou de jongler avec les certificats ssh.

Il faut ensuite vérifier les packages qui nécessitent une compilation locale par un.

emerge -uDNg --rebuilt-binaries -vpe --binpkg-respect-use @world | grep ebuild

La majorité du temps, ça sera dû à des flags USEs différents ... ce qu'indique clairement le résultat de la commande ci-dessus.

Les mise-à-jour des packages se fera par les commandes :

emerge -uDNg --rebuilt-binaries --binpkg-respect-use @world
emerge --depclean

Si on souhaite installer un nouveau package, on remplacera @world par son nom.

Comme je l'indiquais précédemment, il est possible de générer après coup les packages binaires. J'ai essayé de le faire pour copier le système de bPI vers Torchwood ... expérience mitigée comme nous allons le voir.

quickpkg attend en argument la liste des packages (au sens portage du terme) pour lesquels il faut créer le binaire.

Par exemple :

quickpkg "sys-devel/gcc"

mais, on peut faire une copie totale du système par

quickpkg "*/*"

(oui oui, je ne me suis pas foulé, les exemples viennent de la doc).

Pour des raisons de sécurité, les fichiers de configuration ne sont pas inclus par quickpkg ... sauf que ça rend les packages ainsi générés parfaitement inutilisables, car les scripts d'arrêt démarrage eux aussi manqueront .
Bref, mon premier essai a été infructueux : la moitier du système ne démarrait plus et, pour le reste, il était difficile de savoir quels étaient les fichiers absents.

2 options viennent à notre aide :

  --include-config <y|n>
                        include all files protected by CONFIG_PROTECT (as a
                        security precaution, default is 'n')
  --include-unmodified-config <y|n>
                        include files protected by CONFIG_PROTECT that have
                        not been modified since installation (as a security
                        precaution, default is 'n')

J'ai préféré jouer la sécurité en utilisant l'option

--include-config=y

mais les packages étant générés depuis un système en prod, donc avec des configs adaptées à mon réseau, il est important de restreindre leur diffusion à des machines de confiances.

Un exemple d'utilisation avec le clonage de bPI sur Torchwood.