| View previous topic :: View next topic |
| Author |
Message |
mike155
Advocate
Joined: 17 Sep 2010
Posts: 4438
Location: Frankfurt, Germany
|
|
| Back to top |
|
 |
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
 Posted: Sat Jul 21, 2018 4:47 pm Post subject: |
 |
|
| mike155 wrote: | | Meines Erachtens sieht das gut aus |
Wenn man so systemnah sein muss, dass man viele #ifdef's braucht, macht das nie Spaß. Bei eix ist src/various/drop_permissions.cc oder die Funktion normalize_path/NORMALIZE_PATH aus src/eixTk/filenames.cc so ein (Albtraum-)Fall. Aber wenn es halt auf vielen Systemen mit dem selben Source-Code gehen soll, bleibt nicht viel anderes übrig als solches Gemurckse. |
|
| Back to top |
|
|
schmidicom
Veteran
Joined: 09 Mar 2006
Posts: 1924
Location: Schweiz
|
| Posted: Thu Jul 26, 2018 2:43 pm Post subject: |
|
|
@Thema
Ich finde schon das es Bereiche gibt in denen Gentoo nicht wirklich einfacher geworden ist, wenn es zum Beispiel um den 32bit-Support auf einer 64bit-Installation geht.
Bitte nicht falsch verstehen, ich finde das neue System mit der Umgebungsvariable ABI_X86 eigentlich ziemlich gut. Vor allem muss man dadurch die 32bit-Teile nicht mehr als vorkompiliertes Paket hin nehmen.
Aber die nachträgliche Umstellung ist die reinste "Error: circular dependencies:"-Hölle.
Es wäre echt schön wenn Portage irgendwann mal lernen würde solche Abhängigkeiten selber zu lösen ohne das man dafür das halbe System auseinander nehmen muss.
_________________
Lenovo - ThinkPad P16s Gen 2 - 21K9CTO1WW |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Thu Jul 26, 2018 3:20 pm Post subject: |
|
|
| schmidicom wrote: | | Es wäre echt schön wenn Portage irgendwann mal lernen würde solche Abhängigkeiten selber zu lösen |
Kann es ja im Prinzip: Du brauchst nur die entsprechenden Einträge aus Deinem /etc/portage/package.use entfernen und portage seine Vorschläge schreiben zu lassen (die Optionen dafür weiß ich jetzt nicht auswendig). Ob es zweckmäßig ist, das grundsätzlich nicht über package.use zu regeln, sondern portage bestimmte USE-flags nur automatisch entscheiden zu lassen - das hat viele Vor- und Nachteile, die ich jetzt nicht alle diskutieren will. Einer der Hauptnachteile wäre jedenfalls die Geschwindigkeit von emerge, denn ohne die "Hints" aus package.use müsste portage die Dendency-Hölle bei jedem Aufruf alleine lösen, und die ist halt ihrem Wesen nach NP-vollständig. Natürlich könnte man die "Hints" aus Disk cachen, aber das hat auch wieder Nachteile. In jedem Fall müsste ein großer Teil von portage neu implementiert werden. Aber daran führt auf längere Sicht vermutlich ohnehin kein Weg vorbei. Nur will es niemand machen... |
|
| Back to top |
|
|
mike155
Advocate
Joined: 17 Sep 2010
Posts: 4438
Location: Frankfurt, Germany
|
| Posted: Thu Jul 26, 2018 3:44 pm Post subject: |
|
|
| Quote: | | wenn es zum Beispiel um den 32bit-Support auf einer 64bit-Installation geht. |
Die Frage ist natürlich, ob Du den 32 Bit Support überhaupt noch brauchst! Vor einigen Jahren brauchte man 32 Bit Support, aber seit ca. 3 Jahren geht es auch gut ohne.
Brauchst Du 32 Bit Support?
Wenn nicht, dann schmeiß ihn einfach raus. Ich habe alle meine Server vor 3 Jahren auf 64 Bit only umgestellt - und es bisher kein einziges Mal bereut. Das Compilieren einiger Pakete geht schneller und es gibt keinen Ärger mehr mit den 32 Bit Paketen. |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Thu Jul 26, 2018 3:50 pm Post subject: |
|
|
| mike155 wrote: | | Brauchst Du 32 Bit Support? |
Wer irgendwelche Legacy-Anwendungen für wine hat, kommt nicht drum herum. |
|
| Back to top |
|
|
nisto
n00b
Joined: 29 Nov 2014
Posts: 59
Location: Magdeburg (Germany)
|
| Posted: Fri Jul 27, 2018 2:25 am Post subject: |
|
|
| mike155 wrote: | | Quote: | | wenn es zum Beispiel um den 32bit-Support auf einer 64bit-Installation geht. |
... dann schmeiß ihn einfach raus ... |
Moin.
Wie gehe ich da am besten vor? |
|
| Back to top |
|
|
Yamakuzure
Advocate
Joined: 21 Jun 2006
Posts: 2283
Location: Adendorf, Germany
|
| Posted: Fri Jul 27, 2018 8:16 am Post subject: |
|
|
| mv wrote: | | mike155 wrote: | | Brauchst Du 32 Bit Support? |
Wer irgendwelche Legacy-Anwendungen für wine hat, kommt nicht drum herum. |
Nicht unbedingt Legacy. Selbst modernste Software wird gerne als 32bit-Anwendung geliefert. Warum sollte ein Softwareherstellung auch für WIN64 entwickeln, wenn WIN32 bis zum jüngsten Tag unterstützt werden wird?
Von dem Umstand mal abgesehen, dass verwendete Bibliotheken von Drittanbieter gerne nur für 32bit vorliegen, und dann hast du den Salat.
_________________
Important German:- "Aha" - German reaction to pretend that you are really interested while giving no f*ck.
- "Tja" - German reaction to the apocalypse, nuclear war, an alien invasion or no bread in the house.
|
|
| Back to top |
|
|
mike155
Advocate
Joined: 17 Sep 2010
Posts: 4438
Location: Frankfurt, Germany
|
| Posted: Fri Jul 27, 2018 9:46 am Post subject: |
|
|
| Quote: | Moin.
Wie gehe ich da am besten vor?
|
Wenn ich mich richtig erinnere, geht es folgendermaßen:
- Folgende Anweisungen müssen einwandfrei durchlaufen
| Code: | emerge --update --deep --newuse -pv @world
emerge --depclean |
Mit
| Code: | eselect profile list
eselect profile set ... |
wählt uns setzt man ein no-multilib Profil. Ich verwende beispielsweise "default/linux/amd64/17.0/no-multilib"
Wegen des kranken Profil-Konzepts fehlen jetzt sehr wahrscheinlich einige USE-Flags - das hängt davon ab, welches Profil man vorher hatte. Man kann folgendes eingeben:
| Code: | | emerge --update --deep --newuse -pv @world |
und sich aus der Ausgabe die USE-Flags raussuchen, die fehlen. Die fehlenden USE-Flags kann man von Hand in make.conf oder - wenn man feiner unterteilen will - in package.use eintragen.
Ein erneuter Aufruf von "emerge --update --deep --newuse -pv @world" sollte dann nur noch Pakete anzeigen, die wegen des Wechsels von multilib nach no-multilib compiliert werden müssen - und keine, die wegen Änderungen bei den USE-Flags neu compiliert werden müssen.
Jetzt kann man "emerge --update --deep --newuse @world" laufen lassen. Einige Pakete werden neu compiliert, dabei verschwindet der 32 Bit Support.
Zum Schluss kann man noch den Support für 32 Bit Binaries in der Kernel-Config deaktivieren und einen neuen Kernel bauen.
Der Weg zurück von no-multilib nach multilib ist deutlich schwieriger. Einige Quellen verweisen darauf, dass es nur mit einer Neu-Installation geht. Mit Google findet man auch ein paar Anleitungen, wie es geht - aber das ist nicht ganz einfach. |
|
| Back to top |
|
|
Erdie
Advocate
Joined: 20 May 2004
Posts: 2576
Location: Heidelberg - Germany
|
| Posted: Fri Jul 27, 2018 11:11 am Post subject: |
|
|
Ich bin ja schon lange dabei, sehe mich aber mehr als Linux Poweruser. Programmiert habe ich nicht sehr viel und entsprechend wenig Erfahrung. Aus User Sicht habe ich nicht das Gefühl, dass es komplizierter geworden ist. Oder sagen wir mal so: Situationen, bei denen ich das Gefühl hatte, nicht mehr weiterzukommen, sind seltener geworden. Ich bin nach wie vor mit Gentoo zufrieden. Immer, wenn ich mich mit anderen Systemen auseinandersetzen muß (vor allem Ubuntu in der Firma), weiß ich zu schätzen, was ich an Gentoo habe.
Der Ansatz, ein System möglichst lange leben zu lassen, ist bei den meisten Systemen nicht mehr im Fokus. Heute gilt Ex- und Hopp. Gentoo ist die große Ausnahme und das macht es sehr wertvoll.
_________________
Desktop AMD Ryzen 9 5900X 32GB RAM, Asus GF GTX 1060.
Notebook Tuxedo Pulse 15 Gen1 AMD Ryzen 7 4800H mit Radeon Vega 7
Raspberry Pi 1 + 2 + 3B+ + Zero W
Last edited by Erdie on Sat Jul 28, 2018 12:59 pm; edited 1 time in total |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Sat Jul 28, 2018 8:24 am Post subject: |
|
|
Zur Ergänzung von mike155s Hinweisen:
Wenn es Dir nur um die Vermeidung der USE-Abhängigkeiten geht, ist es nicht notwendig, auf no-multilib profile umzustellen:
no-multilib bedeutet, dass eben selbst die toolchain (genauer: gcc und glibc) nur die 64-Bit-Bibliotheken bauen (während diese sonst immer die 32-Bit Bibliotheken "mit"-bauen).
Die 32-Bit-Bibliotheken der Toolchain brauchen nicht sehr viel Platz und auch nicht lange zum kompilieren, aber wie mike155 schrieb: Einmal auf no-multilib umgestellt, kommst Du praktisch nicht mehr zurück.
Zum "Testen", ob Du ohne multilib auskommst, einfach alle "ABI_X86: 32"- bzw. "abi_x86_32"-Einträge in der packag.use entfernen (und ev. ABI_X86="-32 64" in der make.conf setzen). Danach das übliche | Code: | | emerge -NaDu --with-bdeps=y @world |
Edit: Nicht vergessen: Wenn Du Windows-Programme mit wine benutzt und nicht ganz sicher bist, dass diese 64-Bit sind, unbedingt diese danach testen. Auch alte DOS-Programme (dosbox o.ä.) werden nach der Umstellung natürlich nicht mehr gehen. |
|
| Back to top |
|
|
Yamakuzure
Advocate
Joined: 21 Jun 2006
Posts: 2283
Location: Adendorf, Germany
|
| Posted: Mon Jul 30, 2018 11:03 am Post subject: |
|
|
| mv wrote: | | Auch alte DOS-Programme (dosbox o.ä.) werden nach der Umstellung natürlich nicht mehr gehen. |
*seufz* Ich werde sicher niemals auf MoO2 verzichten können...
_________________
Important German:- "Aha" - German reaction to pretend that you are really interested while giving no f*ck.
- "Tja" - German reaction to the apocalypse, nuclear war, an alien invasion or no bread in the house.
|
|
| Back to top |
|
|
|
Deutsches Forum (German) 
Und ich finde es prima, dass mv seinen Code auch veröffentlicht!
