View previous topic :: View next topic |
Author |
Message |
schmidicom Veteran
Joined: 09 Mar 2006 Posts: 1972 Location: Schweiz
|
Posted: Sun Apr 28, 2013 3:45 pm Post subject: Ersetzt "ABI_X86" die emul-libs? |
|
|
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? _________________ Lenovo - ThinkPad P16s Gen 2 - 21K9CTO1WW |
|
Back to top |
|
|
py-ro Veteran
Joined: 24 Sep 2002 Posts: 1734 Location: Velbert
|
Posted: Sun Apr 28, 2013 8:47 pm Post subject: |
|
|
Ja. |
|
Back to top |
|
|
mrueg Retired Dev
Joined: 08 Jul 2012 Posts: 36 Location: Berlin, Deutschland
|
Posted: Mon Apr 29, 2013 3:34 am Post subject: |
|
|
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. |
|
Back to top |
|
|
schmidicom Veteran
Joined: 09 Mar 2006 Posts: 1972 Location: Schweiz
|
Posted: Mon Apr 29, 2013 8:42 am Post subject: |
|
|
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. _________________ Lenovo - ThinkPad P16s Gen 2 - 21K9CTO1WW |
|
Back to top |
|
|
mv Watchman
Joined: 20 Apr 2005 Posts: 6780
|
Posted: Mon Apr 29, 2013 5:46 pm Post subject: |
|
|
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... |
|
Back to top |
|
|
schmidicom Veteran
Joined: 09 Mar 2006 Posts: 1972 Location: Schweiz
|
Posted: Mon Apr 29, 2013 6:34 pm Post subject: |
|
|
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. _________________ Lenovo - ThinkPad P16s Gen 2 - 21K9CTO1WW |
|
Back to top |
|
|
mv Watchman
Joined: 20 Apr 2005 Posts: 6780
|
Posted: Mon Apr 29, 2013 6:50 pm Post subject: |
|
|
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. |
|
Back to top |
|
|
schmidicom Veteran
Joined: 09 Mar 2006 Posts: 1972 Location: Schweiz
|
Posted: Tue Apr 30, 2013 5:37 am Post subject: |
|
|
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? _________________ Lenovo - ThinkPad P16s Gen 2 - 21K9CTO1WW |
|
Back to top |
|
|
mv Watchman
Joined: 20 Apr 2005 Posts: 6780
|
Posted: Tue Apr 30, 2013 11:57 am Post subject: |
|
|
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. |
|
Back to top |
|
|
schmidicom Veteran
Joined: 09 Mar 2006 Posts: 1972 Location: Schweiz
|
Posted: Tue Apr 30, 2013 12:08 pm Post subject: |
|
|
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. _________________ Lenovo - ThinkPad P16s Gen 2 - 21K9CTO1WW |
|
Back to top |
|
|
mv Watchman
Joined: 20 Apr 2005 Posts: 6780
|
Posted: Tue Apr 30, 2013 10:19 pm Post subject: |
|
|
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. |
|
Back to top |
|
|
schmidicom Veteran
Joined: 09 Mar 2006 Posts: 1972 Location: Schweiz
|
Posted: Wed May 01, 2013 7:08 am Post subject: |
|
|
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. _________________ Lenovo - ThinkPad P16s Gen 2 - 21K9CTO1WW |
|
Back to top |
|
|
schmidicom Veteran
Joined: 09 Mar 2006 Posts: 1972 Location: Schweiz
|
Posted: Sun May 05, 2013 2:30 pm Post subject: |
|
|
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? _________________ Lenovo - ThinkPad P16s Gen 2 - 21K9CTO1WW |
|
Back to top |
|
|
CodAv Apprentice
Joined: 09 May 2004 Posts: 170 Location: Essen, Germany
|
Posted: Tue May 07, 2013 7:31 pm Post subject: |
|
|
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.
Code: | 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. _________________ Debian is available in three different versions: rusty, stale and broken. |
|
Back to top |
|
|
musv Advocate
Joined: 01 Dec 2002 Posts: 3365 Location: de
|
Posted: Wed May 08, 2013 8:50 am Post subject: |
|
|
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). |
|
Back to top |
|
|
mv Watchman
Joined: 20 Apr 2005 Posts: 6780
|
Posted: Wed May 08, 2013 12:56 pm Post subject: |
|
|
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. |
|
Back to top |
|
|
schmidicom Veteran
Joined: 09 Mar 2006 Posts: 1972 Location: Schweiz
|
Posted: Mon Jul 08, 2013 4:38 pm Post subject: |
|
|
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? _________________ Lenovo - ThinkPad P16s Gen 2 - 21K9CTO1WW |
|
Back to top |
|
|
Max Steel Advocate
Joined: 12 Feb 2007 Posts: 2270 Location: My own world! I and Gentoo!
|
Posted: Mon Jul 08, 2013 4:49 pm Post subject: |
|
|
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) _________________ mfg
Steel
___________________
Heim-PC: AMD Ryzen 5950X, 64GB RAM, GTX 1080
Laptop: Intel Core i5-4300U, 16GB RAM, Intel Graphic
Arbeit-PC: Intel i5-1145G7, 16GB RAM, Intel Iris Xe Graphic (leider WSL2) |
|
Back to top |
|
|
schmidicom Veteran
Joined: 09 Mar 2006 Posts: 1972 Location: Schweiz
|
Posted: Tue Jul 09, 2013 9:35 am Post subject: |
|
|
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:
Code: | 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... _________________ Lenovo - ThinkPad P16s Gen 2 - 21K9CTO1WW |
|
Back to top |
|
|
|