# Multilib-Strategie gesucht

## musv

Guten Nachmittag, 

ich quäl mich nach langer Zeit mal wieder durch ein Systemupdate (~amd64), bei dem wie gewohnt ziemlich viel fehlschlägt. Das ist soweit ok für mich. 

Mittlerweile bin ich aber an ein Problem gekommen, bei dem es mich dieser Bug zum Nachdenken brachte, ob ich Multilib überhaupt systemweit will und brauch. An 32-Bit-Anwendungen hab ich eigentlich nur Google Earth (bei dem man die Bilder nur über einen Hack zum Laufen bringt) und diverse Spiele, die halt aufgrund der Portierung von Windows nur in 32bit verfügbar sind. 

Jetzt stellt sich mir die Frage nach der Sinnhaftigkeit, sämtliche Libs sowohl in 32bit als auch 64bit verfügbar haben zu müssen. 

Gedanken wären da:

Gar nichts nativ multilib, sondern die 32bit-Sachen über einen Docker laufen zu lassen. Geht das mit den nvidia-Treibern?

Nur die Nvidia-Treiber als multilib und den Rest als Docker.

Nur Multilib aktivieren, wenn sich eine Anwendung aktiv beschwert. Dann hat man aber noch immer Multilib aktiviert und muss halt schrittweise immer compilieren und fummeln, wenn irgendwas 32-Bittiges nicht will. 

Oder doch das ganze System als Multilib installiert lassen?

Was davon ist die am wenigsten dreckigste Lösung?

----------

## kurisu

Ich fahre Strategie 3, setzte abi_x86_32 also selektiv immer nur lokal. Sofern man alles sauber über Ebuilds verwaltet, lässt sich das Gefrickel weitgehend in Grenzen halten beziehungsweise bleibt es bei einer einmaligen Angelegenheit pro Programm.

In meinem Fall werden vor allem für Wine, jedoch auch zunehmend für ein paar ältere 32 Bit Windows Spiele, die mittlerweile ja über diverse Plattformen als Portierungen für Linux verfügbar sind, 32 Bit Bibliotheken benötigt. (Außer natürlich man verwendet die bundled libraries, aber genau das möchten wir bei Gentoo ja üblicherweise vermeiden.) Mit selbst geschriebenen Ebuilds lässt sich das für mich recht bequem handhaben.

Insgesamt habe ich laut

```
grep abi_x86_32 /etc/portage/package.use | wc -l
```

aktuell 97 Libraries zusätzlich in der 32 Bit Variante installiert. Den Großteil macht alleine Wine aus. Eine nicht unerhebliche Menge. Wäre ABI_X86 aber global auf multilib gesetzt, käme ich auf meinem System derzeit auf insgesamt 277, also annähernd das Dreifache. Zwei Drittel wären demnach entbehrlich. Zumeist spielen Rechenaufwand und Speicherbedarf heute zwar keine große Rolle mehr, jedoch ist das nicht die für Gentoo typische Vorgehensweise. Funktionieren wird sicher beides, effizienter und schöner scheint mir aber der selektive Weg.

Zu Docker kann ich mangels Erfahrung nichts sagen.

----------

## musv

Nach einiger Überlegung gehe ich jetzt auch den Weg. 

Bisher hatte ich abi_x86_32 global in der make.conf gesetzt. Jetzt hab ich in package.use/ eine multilib.use angelegt, in der ich alle Pakete, für die 32bit gefordert wird, eintrag. 

Und bei der Gelegenheit hab ich auch mal wine etwas entrümpelt und da diverse Unterstützungen, z.B. scanner rausgenommen, um die Abhängigkeiten zu reduzieren. Der Rattenschwanz ist aber trotzdem noch groß genug.

----------

## kurisu

Ja, ich erinnere mich. Als multilib im Frühling letzten Jahres nach stable kam war es vor allem Wine, das mich einen Moment lang zweifeln ließ, ob mich dieser selektive Weg langfristig wirklich glücklich machen wird. Am Ende war das dann aber doch an einem Abend zu bewältigen und hat sich seitdem nicht wiederholt. Alles andere ließ und lässt sich stets mit sehr wenig Aufwand lösen.

Docker klingt übrigens interessant. Wenn ich mal Zeit und Lust habe, werde ich die eingangs genannten Szenarien vielleicht einmal durchexerzieren.

----------

## musv

Docker hat im Grunde genommen den Vorteil, dass du Dir 'ne fertige Distri runterladen kannst: 

https://hub.docker.com/explore/

Deine Änderungen packst du einfach als Slice obendrauf. 

Nachteil an der Lösung: Du hast halt immer ein halbes Linux zusätzlich im Einsatz, nur um ein Programm laufen zu lassen.

Vorteil: Laufen bestimmte Programme (Steam?) nur mit viel Gefrickel unter Gentoo, dann nimmst du einfach das Distri-Image, für die das Programm geschrieben wurde. 

Falls du Systemd verwendest, kannst du auch einfach systemd-nspawn verwenden. Macht im Grunde genommen auf den ersten Blick nicht soviel anders. 

https://www.flockport.com/a-quick-look-at-systemd-nspawn-containers/

Ich nutz derzeit nspawn als arm-chroot, um irgendwie mal meine NAS zum laufen zu kriegen.

----------

## toralf

 *musv wrote:*   

> ich quäl mich nach langer Zeit mal wieder durch ein Systemupdate (~amd64), bei dem wie gewohnt ziemlich viel fehlschlägt. Das ist soweit ok für mich.

 Upmf, wirklich ?

Andreerseits, ich laß tgl. ein "emerge --update @world --ask --deep" vllt. verhindert das ja eine größere Pein.

----------

## Child_of_Sun_24

Ich bin gerade dabei die 32Bit Libs von meinem System zu verbannen, werde sie in Zukunft nur bei bedarf aktivieren.

Hatte Probleme dev-lang/mono-4.6 und aktuell 4.9 mit abi_x86_32 und dem gold Linker zu Kompilieren (Es funktioniert mit dem 64 Bit Teil astrein nur der 32 Bit Part meckert). Daraufhin habe ich beschlossen es mal ohne 32Bit zu versuchen.

Bis jetzt läuft alles astrein.

----------

