# Ersetzt "ABI_X86" die emul-libs?

## schmidicom

Ich versuche schon seit einiger Zeit genau diese Frage mit Hilfe von Google zu beantworten doch so richtig erfolgreich war ich damit nicht. Deshalb stell ich diese Frage jetzt einfach mal hier in den Raum und hoffe auf etwas mehr Klarheit.

Ist meine Vermutung das dieses Flag irgendwann die emul-libs ersetzt richtig?

----------

## py-ro

Ja.

----------

## mrueg

Jein, es gibt zwei verschiedene Ansätze 32bit binaries zu ersetzen. Einmal multilib-portage und einmal das eclass-basierte, dass du mit ABI_X86 siehst.  Ersteres lebt in einem eigenem Repository, zweiteres wurde im Tree mittels "Invasion" durchgesetzt. Welcher Ansatz am Ende benutzt wird, ist noch offen, vermutlich wird es aber der eclass basierte. 

Im Moment kann man jedoch die emul-linux-x86-xlibs bereits durch den eclass basierten ansatz ersetzen, falls man das ganze mal ausprobieren möchte.

----------

## schmidicom

 *mrueg wrote:*   

> Ersteres lebt in einem eigenem Repository, zweiteres wurde im Tree mittels "Invasion" durchgesetzt.

 

Hier verstehe ich jetzt nicht so ganz was du damit sagen willst.

----------

## mv

 *schmidicom wrote:*   

> Hier verstehe ich jetzt nicht so ganz was du damit sagen willst.

 

Es sind nicht alle mit diesem Ansatz einverstanden, weil er verschiedene Nachteile hat. Wenn Du z.B. ein Binary hast, das eine Bibliothek mit USE=pulseaudio benötigt, musst Du diese Bibliothek automatisch auch im 64-Bit-Modus mit diesem USE-Flag bauen, d.h. Du musst dann automatisch pulseaudio auch im 64-Bit-Modus benutzen, obwohl das bislang nicht nötig war.

Die multilib-Portage Lösung war meines Wissens diesbezüglich eine deutlich flexiblere Implementierung, aber ihre Entwickler wurden durch andere Entwickler vor fertige Tatsachen gestellt...

----------

## schmidicom

Danke für die Erklärung, doch so ganz Sinnvoll erscheint mir diese "Abneigung einiger" nicht. Auf mich wirkt das Vorhaben innerhalb des selben System auf 32bit etwas anderes machen zu wollen als auf 64bit wie wenn der Verwalter selbst nicht weis was er will.

Aber egal, ich finde es gut den dadurch bleiben die 32bit libs auf dem selben Stand wie die 64bit libs und es dauert nicht mehr Ewigkeiten bis ein Bug behoben wird nur weil es bei den emul-libs kein Update gibt.

----------

## mv

 *schmidicom wrote:*   

> Auf mich wirkt das Vorhaben innerhalb des selben System auf 32bit etwas anderes machen zu wollen als auf 64bit wie wenn der Verwalter selbst nicht weis was er will.

 

Beispiel: Nur weil Skype zwingend pulseaudio benötigt muss ich jetzt praktisch alle Programme ebenfalls mit pulseaudio als Backend bauen, obwohl ich pulseaudio so dringend will wie die Krätze - als wäre es nicht schlimm genug, bei Benutzung von Skype die Soundstörungen durch pulseaudio zu haben. Schlimmer noch: Ich muss vermutlich mein 64-Bit System auf pam, ldap u.v.a. umstellen, nur weil vielleicht eine einzelne proprietäre 32-Bit-Anwendung auf eine Bibliothek davon zugreifen muss.

Und das alles ohne sachliche Gründe, sondern nur, weil die Implementation zu "dumm" ist.

----------

## schmidicom

Wenn das 32bit Skype Pulseaudio will dann muss Pulseaudio mit der neuen Methode sowohl in 32 als auch in 64bit installiert sein, das verstehe ich, aber deswegen ist man doch noch lange nicht gezwungen Pulsaudio auch in allen anderen Programmen zu verwenden?

----------

## mv

 *schmidicom wrote:*   

> Wenn das 32bit Skype Pulseaudio will dann muss Pulseaudio mit der neuen Methode sowohl in 32 als auch in 64bit installiert sein, das verstehe ich, aber deswegen ist man doch noch lange nicht gezwungen Pulsaudio auch in allen anderen Programmen zu verwenden?

 

Ich sitze jetzt nicht vor einem Gentoo-Rechner, daher ist das Beispiel jetzt nur hypothetisch:

Beispielsweise will skype qtcore[pulseaudio] (oder gtk++[pulseaudio]) o.ä. Dann werden alle 64bit-Programme, die ihren Sound über qt/gtk++ handeln zwangsläufig pulseaudio benutzen.

----------

## schmidicom

In so einem Fall würde ich mir ernsthaft überlegen ob das 32bit Programm auch wirklich notwendig ist und je nach dem eine von folgenden zwei Optionen akzeptieren:

Entweder das entsprechende 32bit Programm aufgeben oder die damit verbunden Abhängigkeiten akzeptieren.

----------

## mv

 *schmidicom wrote:*   

> In so einem Fall würde ich mir ernsthaft überlegen ob das 32bit Programm auch wirklich notwendig ist

 

Leider ist Verzicht auf Skype z.B. keine Option.

 *Quote:*   

> und je nach dem eine von folgenden zwei Optionen akzeptieren

 

Nur traurig, dass das nur aufgrund der neuen mangelhaften Unterstützung durch den Paketmanager nötig ist: Bisher ging es einwandfrei anders, und m.W. wäre das auch mit der Multilib-Portage-Lösung so.

----------

## schmidicom

Das alte System ist aber auch nicht gerade das gelbe vom Ei.

In den aktuellen emul-libs hat sich wieder mal ein Opengl Bug eingeschlichen der bei Steam ziemlich nervt und egal wie oft ich ein Update laufen lasse die 32bit libs bleiben wie sie sind nämlich verbugt. Mit dem neuen System hoffe ich das sowas dann nicht mehr passiert oder Fehler schneller behoben werden können.

----------

## schmidicom

 *mrueg wrote:*   

> Im Moment kann man jedoch die emul-linux-x86-xlibs bereits durch den eclass basierten ansatz ersetzen, falls man das ganze mal ausprobieren möchte.

 

Gibt es auch eine Möglichkeit das mit "emul-linux-x86-opengl" und "mesa" zu machen oder muss ich warten bis ein ebuild von mesa kommt das dies unterstützt?

----------

## CodAv

 *mv wrote:*   

> Es sind nicht alle mit diesem Ansatz einverstanden, weil er verschiedene Nachteile hat. Wenn Du z.B. ein Binary hast, das eine Bibliothek mit USE=pulseaudio benötigt, musst Du diese Bibliothek automatisch auch im 64-Bit-Modus mit diesem USE-Flag bauen, d.h. Du musst dann automatisch pulseaudio auch im 64-Bit-Modus benutzen, obwohl das bislang nicht nötig war.
> 
> Die multilib-Portage Lösung war meines Wissens diesbezüglich eine deutlich flexiblere Implementierung, aber ihre Entwickler wurden durch andere Entwickler vor fertige Tatsachen gestellt...

 

Diesen Nachteil könnte man vermutlich einfach dadurch beseitigen, indem man einen optionalen ABI-Parameter in die package.use-Syntax einfügt, also z.B.

```
some-category/just-a-lib pulseaudio other use flags

some-category/just-a-lib[abi_x86_32] -pulseaudio
```

Man könnte der Einfachheit halber festlegen, dass Angaben ohne ABI-Typ allgemeingültig sind, und spezifische Angaben dann die anderweitig festgelegten Werte ergänzen oder überschreiben, so dass just-a-lib in der 32-Bit-Version die USE-Flags "-pulseaudio other use flags" erhalten würde.

----------

## musv

 *mv wrote:*   

> Beispiel: Nur weil Skype zwingend pulseaudio benötigt

 

Das ist falsch. Skype funktioniert auf meinem Rechner ohne zu meckern ohne Pulseaudio. Nur mit OSS funktioniert's nicht mehr. Die Entwicklung wurde mit der 2.0.0.72 als letzte Version eingestellt. 

 *schmidicom wrote:*   

> Wenn das 32bit Skype Pulseaudio will dann muss Pulseaudio mit der neuen Methode sowohl in 32 als auch in 64bit installiert sein, das verstehe ich, aber deswegen ist man doch noch lange nicht gezwungen Pulsaudio auch in allen anderen Programmen zu verwenden?

 

Ungenau. Theoretisch ja. Aber Lennart-Applikationen haben die Eigenschaft, dass sie das System infiltrieren und sich zum unverzichtbaren Bestandteil ernennen. Beispiel: Ich hatte bis vor einigen Monaten noch OSS4 als Soundsystem. KDE funktionierte problemlos mit OSS. Dann wollte ich mal Netzwerkstreaming ausprobieren und genau dafür Pulseaudio einsetzen. Kaum hatte ich Pulseaudio zum ersten Mal gestartet, wurde das Ding zum Default-Soundserver im KDE ernannt. Ich hatte keine Möglichkeit, Pulseaudio dort wieder rauszukicken und irgendwie OSS zu reaktivieren. Erst nach dem Rechnerneustart stand mir an der Stelle OSS wieder zur Verfügung (bis zum nächsten Pulseaudio-Start).

----------

## mv

 *musv wrote:*   

>  *mv wrote:*   Beispiel: Nur weil Skype zwingend pulseaudio benötigt 
> 
> Das ist falsch. Skype funktioniert auf meinem Rechner ohne zu meckern ohne Pulseaudio.

 

Dein Wort in Gottes Ohr: Ich habe pulseaudio nur in den 32-Bit-Libraries wie zwangsweise jede Skype-Benutzer unter Linux derzeit, und wenn ich Skype aufrufe, wird ein ~/.pulseaudio angelegt: Also nahm ich an, dass skype pulseaudio implizit erfordert und dementsprechend künftig davon abhängen wird. Ein Beweis ist das natürlich nicht, und ich hoffe sehr, dass Du recht hast.

----------

## schmidicom

Gibt es nun eine Möglichkeit früher als geplant von der veralteten emul-libs auf die neue ABI Variante umzustellen?

Vielleicht mit Hilfe eines Overlays?

----------

## Max Steel

 *schmidicom wrote:*   

> Gibt es nun eine Möglichkeit früher als geplant von der veralteten emul-libs auf die neue ABI Variante umzustellen?
> 
> Vielleicht mit Hilfe eines Overlays?

 

Das Steam-Overlay verwendet die ABI-Variante momentan ziemlich flächendeckend. Größtenteils müssen dafür scheinbar noch große Teile der Abhängigkeiten in den Ebuilds umgebaut werden damit man die eine oder andere Variante auswählen kann. (denke ich)

----------

## schmidicom

Das steam Overlay habe ich schon länger aktiv aber das alleine reicht leider noch nicht aus.

Inzwischen habe ich noch die beiden anderen Overlays "multilib" und "multilib-portage" ausprobiert aber ersteres scheint nicht mehr kompatibel zu sein und beim letzteren kommt das:

```
slap ~ # emerge -pv =app-emulation/emul-linux-x86-opengl-99999999

These are the packages that would be merged, in order:

Calculating dependencies... done!

The following keyword changes are necessary to proceed:

 (see "package.accept_keywords" in the portage(5) man page for more details)

# required by =app-emulation/emul-linux-x86-opengl-99999999 (argument)

=app-emulation/emul-linux-x86-opengl-99999999 ~amd64

emerge: there are no ebuilds built with USE flags to satisfy "media-libs/mesa[multilib_abi_x86]".

!!! One of the following packages is required to complete your request:

- media-libs/mesa-9.1.2-r1::gentoo (Missing IUSE: multilib_abi_x86)

- media-libs/mesa-9.0.1::gentoo (Missing IUSE: multilib_abi_x86)

- media-libs/mesa-8.0.4-r1::gentoo (Missing IUSE: multilib_abi_x86)

- media-libs/mesa-7.11.2::gentoo (Missing IUSE: multilib_abi_x86)

- media-libs/mesa-7.10.3::gentoo (Missing IUSE: multilib_abi_x86)

(dependency required by "app-emulation/emul-linux-x86-opengl-99999999::multilib[-nodep]" [ebuild])

(dependency required by "=app-emulation/emul-linux-x86-opengl-99999999" [argument])
```

Was Portage da sagen will ist mir klar nur woher ein aktuelles mesa ebuild mit ABI nehmen? Das einzige das sich auf zugaina finden lässt ist eines das direkt ab source ohne Versionsangabe baut und das ist mir dann doch eine spur zu experimentell.

Da bleibt einem wohl nichts anderes übrig als zu warten bis die ABI auch bei mesa angekommen ist...

----------

