Je dois révéler que j'ai peu d'expérience en utilisant multilib-build.eclass
-style multilib dans Gentoo.
ABI_X86
est une USE_EXPAND
variable; réglage ABI_X86="32 64"
ou USE="abi_x86_32 abi_x86_64"
sont équivalentes. Le paramètre par défaut de ABI_X86, au moment de la rédaction de ce document (2013-09-09), pour le default/linux/amd64/13.0
profil semble être juste ABI_X86=64
.
Cette variable contrôle la prise en charge explicite de multilib dans les ebuilds qui utilisent multilib-build.eclass
une méthode plus gentoo-like de faire multilib que la méthode originale.
La méthode d'origine selon laquelle les bibliothèques 32 bits seraient installées dans Gentoo est via les instantanés binaires nommés app-emulation/emul-linux-*
. Chacun de ces paquets binaires d'émulation contient un ensemble complet de bibliothèques 32 bits compilées par un développeur Gentoo pour vous. Étant donné que chacun installe un ensemble de bibliothèques qui doivent être coordonnées ensemble, le suivi des dépendances des ebuilds 32 bits uniquement est plus difficile. Par exemple, si vous avez besoin d'un 32 bits media-libs/alsa-lib
sur un système 32 bits, vous venez d'installer media-libs/alsa-lib
, mais sur un système multilib 64 bits, vous devez découvrir qui app-emulation/emul-linux-soundlibs
installe, entre autres bibliothèques, la version 32 bits de media-libs/alsa-lib
. De plus, le développeur Gentoo qui construit un de ces packages binaires doit faire le travail pour déterminer les bizarreries multilib et buildsystem de chaquedes bibliothèques incluses dans le package d'instantanés, ce qui rend la maintenance plus difficile. Et, plus important encore, fournir des packages binaires comme seule option officielle pour utiliser multilib dans Gentoo va à l'encontre de l'esprit de Gentoo. Vous devriez avoir le droit de tout compiler vous-même!
Il multilib-build.eclass
s'éloigne de ce comportement en aidant les ebuilds individuels à installer les versions 32 bits et 64 bits. Cela devrait permettre, par exemple, wine
d'avoir uniquement besoin de spécifier les dépendances directement par rapport aux packages dont il a besoin au lieu d'avoir à extraire les app-emulation/emul-linux-*
packages. Comme le mentionne ssuominen dans le fil de discussion auquel vous avez fait référence :
= app-emulation / emul-linux-x86-xlibs-20130224-r1 qui est un paquet vide qui n'a pas de fichiers car les fichiers proviennent maintenant directement des x11-libs /
(Notez qu'il -r1
a depuis été renommé -r2
) Finalement, app-emulation/emul-linux-x86-xlibs
lui - même devrait pouvoir être supprimé car les packages 32 bits uniquement dépendent directement des packages corrects dans la mesure x11-libs
où, avec multilib-build.eclass
l'aide de, fournissent les bibliothèques 32 bits nécessaires. C'est là ABI_X86
qu'entre en jeu. Tout multilib-build.eclass
package activé gagne au moins les nouveaux drapeaux USE abi_x86_32
et abi_x86_64
et probablement abi_x86_x32
. En utilisant les EAPI=2
dépendances -style USE , les packages peuvent dépendre des versions 32 bits d'autres packages. Si x11-libs/libX11
est émergé alors ABI_X86="32 64"
, il doit être installé avec l'ensemble USE-flags abi_x86_32
et abi_x86_64
USE-flags. Si un package graphique particulier a besoin d'une version 32 bits de libX11
, il peut spécifierx11-libs/libX11[abi_x86_32]
dans ses dépendances. De cette façon, si vous essayez d'émerger ce package graphique et que vous n'avez libX11
pas installé de bibliothèques 32 bits, portage refusera. multilib-build.eclass
est également universel et est compatible avec les systèmes 32 bits: l'installation de ce même package graphique sur un système 32 bits fonctionnera toujours car il est impossible d'installer libX11
sans que son abi_x86_32
indicateur d'utilisation soit défini. Cela résout le problème de devoir dépendre de app-emulation/emul-linux-x86-xlibs
quand sur un système multilib et directement x11-libs/libX11
sur un système 32 bits uniquement. Nous ouvrons la voie à des dépendances inter-packages plus propres et plus sensibles sur les systèmes multilib. =app-emulation/emul-linux-x86-xlibs-20130224-r2
existe en tant qu'intermédiaire qui permet à tous les anciens paquets qui dépendaient de app-emulation/emul-linux-x86-xlibs
qui ne savent pas dépendre directement, par exemple x11-libs/libX11[abi_x86_32]
, de continuer à fonctionner.=app-emulation/emul-linux-x86-xlibs-20130224-r2
s'assure que les mêmes bibliothèques 32 bits existent /usr/lib32
comme si elles =app-emulation/emul-linux-x86-xlibs-20130224
avaient été installées, mais le fait de la manière Gentoo en construisant ces bibliothèques 32 bits via ses dépendances plutôt qu'en fournissant un paquet binaire. Il se comporte de la même manière que les packages de la virtual
catégorie: il n'installe rien, juste "transmet" les dépendances pour les ebuilds existants.
Nous avons vu comment multilib-build.eclass
ouvre la voie à des dépendances plus propres sur les systèmes multilib. Tout paquet qui a des ABI_X86
options (c'est la même chose que de dire qu'il a abi_x86_*
useflags) a installé une version 32 bits de lui-même si vous avez spécifié USE=abi_x86_32
/ ABI_X86=32
. Comment cela fonctionne-t-il (à un niveau conceptuel élevé)? Vous pouvez lire l'ebuild lui-même. Fondamentalement, l'idée est la même que les ebuilds python ou ruby qui ont la possibilité de s'installer pour plusieurs versions de python et ruby simultanément. Lorsqu'un ebuild hérite multilib-build.eclass
, il boucle sur ABI_X86 et effectue chaque étape du processus de décompression, de compilation et d'installation pour chaque entrée dans ABI_X86. Étant donné que portage passe par toutes les phases de ebuild comme src_unpack()
, src_compile()
et src_install()
(et d'autres) dans l'ordre et une seule fois,multilib-build.eclass
(actuellement, avec l'aide de multibuild.eclass
) uses crée un répertoire pour chaque valeur différente de ABI_X86. Il décompressera une copie des sources dans chacun de ces répertoires. À partir de là, chacun de ces répertoires commence à diverger car chacun cible un ABI particulier. Le répertoire pour ABI_X86=32
aura ./configure --libdir=/usr/lib32
fonctionné avec FLAGS ciblant 32 bits (par exemple, CFLAGS=-m32
provient de l'envvar CFLAGS_x86 du profil multilib (remarque: les profils de portage se réfèrent principalement à ABI_X86 = 32 comme ABI = x86 et ABI_X86 = 64 comme ABI = amd64)). Pendant lesrc_install()
phase, tous les différents ABI compilés sont installés les uns sur les autres de sorte que lorsque tous les fichiers ont à la fois des versions 32 bits et 64 bits, l'ABI natif gagne (par exemple, un ebuild installant les deux bibliothèques et un exécutable dans PATH n'installerait qu'un 64 -bit exécutable dans PATH mais inclut les bibliothèques 32 bits et 64 bits). Pour résumer: lorsque vous définissez ABI_X86="32 64"
dans make.conf
, tous les paquets qui supports multilib-build.eclass
prendra le montant à peu près deux fois plus de travail (je ne dis pas le temps ;-)) pour compiler car il est construit une fois pour chaque ABI et les résultats dans les bibliothèques 32 bits dans /usr/lib32
.
Je ne sais pas s'il existe encore une documentation officielle ABI_X86
ou son statut détaillé. Les ebuilds utilisant multilib-build.eclass
semblent pour la plupart instables pour le moment. Vous pouvez suivre les instructions sur le blog auquel vous avez lié pour commencer à expérimenter et à tester ABI_X86
si vous comprenez la distinction entre app-emulation/emul-linux-x86-xlibs-20130224
le multilib et le nouveau style app-emulation/emul-linux-x86-xlibs-20130224-r2
. Mais, si vous êtes d'accord avec le paquet binaire à l'ancienne, je pense que cela app-emulation/emul-linux-x86-xlibs-20130224
devrait rester fonctionnel. Vous n'auriez besoin de passer à que -r2
si vous utilisez un package qui dépend directement du abi_x86_32
drapeau d' utilisation d'un autre package (par exemple, app-emulation/emul-linux-x86-xlibs-20130224
et x1-libs/libX11[abi_x86_32]
ne peut pas coexister car ils installent probablement tous les deux la même bibliothèque /usr/lib32
, à savoir /usr/lib32/libX11.so.6
). Un rapideregarder wine-1.7.0.ebuild
me suggère qu'il n'a pas besoin -r2
.
app-emulation/emul-linux-x86
et d'autres dépendaient de leurs homologues directs . Il a fallu beaucoup de mots clés et de changements de drapeau UTILISATION, mais j'ai tout compilé et exécuté avec bonheur ensemble! :-D