• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

SUSE 10.1, x86_64: was sollen die i686 Pakete?

panamajo

Guru
Ich hatte damit schon Probleme und moniert:
http://www.linux-club.de/viewtopic.php?t=61119

Also entweder bin ich der Einzige mit einem Problem damit (warum?) oder alle anderen merken das nicht (unwahrscheinlich) oder was?

Das Problem: nach
Code:
# apt update
# apt upgrade

werden jede Menge Pakete angeboten. Darunter sind aber leider auch i686 optimierte Pakete, die dann die x86_64 Pakete ersetzen - damit ist z.B. bei glibc Schluss mit der Möglichkeit irgendwas unter 64bit zu compilieren. :evil:

Entweder habe ich was falsch verstanden oder die i686 Pakete haben in den x64_86 Repositories schlichtweg nix verloren. Wie (wer, wann) bekommt man die da wieder raus damit apt wieder funktioniert?
 

emoenke

Member
panamajo schrieb:
Ich hatte damit schon Probleme und moniert:
http://www.linux-club.de/viewtopic.php?t=61119

Also entweder bin ich der Einzige mit einem Problem damit (warum?) oder alle anderen merken das nicht (unwahrscheinlich) oder was?

Das Problem: nach
Code:
# apt update
# apt upgrade

werden jede Menge Pakete angeboten. Darunter sind aber leider auch i686 optimierte Pakete, die dann die x86_64 Pakete ersetzen - damit ist z.B. bei glibc Schluss mit der Möglichkeit irgendwas unter 64bit zu compilieren. :evil:

Entweder habe ich was falsch verstanden oder die i686 Pakete haben in den x64_86 Repositories schlichtweg nix verloren. Wie (wer, wann) bekommt man die da wieder raus damit apt wieder funktioniert?

Das geht nicht besser auf der Server-Seite - bei den glibc-Paketen hat i686 höhere Versions-Nummern.

Da müßt ihr die i686-Pakete pinnen.
 
OP
panamajo

panamajo

Guru
emoenke schrieb:
Das geht nicht besser auf der Server-Seite - bei den glibc-Paketen hat i686 höhere Versions-Nummern.
Ich bin der Meinung dass die i686 Pakete fälschlicherweise im x86_64 apt Repository liegen.
i686 sind bei SUSE üblicherweise optimierte Pakete für CPUs neuer als i586 (aka Pentium, Mindestvoraussetzung für SUSE), die für einige wenige Pakete zur Verfügung gestellt werden. glibc ist solch ein Kandidat, denn dort zu optimieren bringt viel bei vergleichsweise geringem Aufwand. Genauso gibt es die packman Pakete ja auch in i686 optimierter Fassung für 32bit (Multimedia profitiert sehr von der Nutzung der MMX/SSE Befehle).
Lässt man ein apt upgrade laufen werden fatalerweise nicht die ggf. installierten i586 Pakete durch die "neueren" i686 Pakete ersetzt/upgedatet sondern die x86_64 Pakete :shock: Im Falle der glibc wars das dann mit 64bit Anwendungen.
In dem o.g. Thread wurde darauf hingewiesen dass die Anwendung apt hierfür keine Lösung bietet (kann nicht zwischen den verschiedenen Arch. unterscheiden). Deshalb bin ich der Meinung dass die i686 Pakete aus dem x86_64 Rep. raus müssen (wie in SUSE 9.3/10.0).
emoenke schrieb:
Da müßt ihr die i686-Pakete pinnen.
glibc ist aber nicht das einzige Paket dass im Repository in allen drei (i586, i686, x86_64) Varianten vorliegt. Und ob da noch welche dazukommen ist auch nicht absehbar...
Sry, einzelne Pakete zu pinnen mag mal eine temporäre Notlösung sein, aber unter diesen Umständen kann man apt für SUSE 10.1 x86_64 vergessen. :(
 

emoenke

Member
panamajo schrieb:
emoenke schrieb:
Das geht nicht besser auf der Server-Seite - bei den glibc-Paketen hat i686 höhere Versions-Nummern.
Ich bin der Meinung dass die i686 Pakete fälschlicherweise im x86_64 apt Repository liegen.

Ich bin der gegenteiligen Meinung.
Ich nehme an, Du theoretisierst nur - wenn Du ein x86_64 System hättest, würdest Du ja gesehen haben, daß dort /lib/ und /usr/lib/ nicht leer sind.

panamajo schrieb:
i686 sind bei SUSE üblicherweise optimierte Pakete für CPUs neuer als i586 (aka Pentium, Mindestvoraussetzung für SUSE), die für einige wenige Pakete zur Verfügung gestellt werden. glibc ist solch ein Kandidat, denn dort zu optimieren bringt viel bei vergleichsweise geringem Aufwand. Genauso gibt es die packman Pakete ja auch in i686 optimierter Fassung für 32bit (Multimedia profitiert sehr von der Nutzung der MMX/SSE Befehle).

Ja genau. Goldrichtig für den 32-Bit-Modus bei x86_64.

panamajo schrieb:
iLässt man ein apt upgrade laufen werden fatalerweise nicht die ggf. installierten i586 Pakete durch die "neueren" i686 Pakete ersetzt/upgedatet sondern die x86_64 Pakete :shock: Im Falle der glibc wars das dann mit 64bit Anwendungen.
In dem o.g. Thread wurde darauf hingewiesen dass die Anwendung apt hierfür keine Lösung bietet (kann nicht zwischen den verschiedenen Arch. unterscheiden). Deshalb bin ich der Meinung dass die i686 Pakete aus dem x86_64 Rep. raus müssen (wie in SUSE 9.3/10.0).
emoenke schrieb:
Da müßt ihr die i686-Pakete pinnen.
glibc ist aber nicht das einzige Paket dass im Repository in allen drei (i586, i686, x86_64) Varianten vorliegt. Und ob da noch welche dazukommen ist auch nicht absehbar...
Sry, einzelne Pakete zu pinnen mag mal eine temporäre Notlösung sein, aber unter diesen Umständen kann man apt für SUSE 10.1 x86_64 vergessen. :(

Du hast das Problem noch nicht scharf genug erkannt.
Wenn eine i586-Version eine höhere Versionsnummer als die x86_64-Version hätte, würde die x86_64-Version auch überbrettert.

Kritisch ist nur, wenn ein Paket für x86_64 eine niedrigere Versionsnummer hat. Kein Grund, auf den 32-Bit-Modus zu verzichten.
 
Die 32-Bit-glibc kommt nicht aus einem i686-Paket (glibc.i686), sondern aus einem x86_64-Paket (glibc-32bit.x86_64).
 
OP
panamajo

panamajo

Guru
emoenke schrieb:
Ich nehme an, Du theoretisierst nur - wenn Du ein x86_64 System hättest, würdest Du ja gesehen haben, daß dort /lib/ und /usr/lib/ nicht leer sind.
Nein, ich theoretisiere nicht.
Ich habe mehrere x86_64 Rechner zu warten (verwende dazu apt) und habe zum Testen einen davon von SUSE 10.0 auf SUSE 10.1 upgedatet, dort tritt das hier dokumentierte Problem auf.

emoenke schrieb:
Du hast das Problem noch nicht scharf genug erkannt.
Wenn eine i586-Version eine höhere Versionsnummer als die x86_64-Version hätte, würde die x86_64-Version auch überbrettert.

Stimmt, Missverständnis der apt policy Ausgabe meinerseits (s.u.).

emoenke schrieb:
Kritisch ist nur, wenn ein Paket für x86_64 eine niedrigere Versionsnummer hat. Kein Grund, auf den 32-Bit-Modus zu verzichten.

Meiner bescheidenen Meinung nach sind für den 32bit Modus die -32bit Pakete zuständig, und diese sind ja auch weiterhin im Repository enthalten (ich ging fälschlicherweise davon aus dass mit SUSE 10.1 die -32bit Pakete gegen i586 ersetzt wurden).
Mir ist trotzdem nicht klar welchem Zweck die i[56]86 Pakete dienen sollten:
Wer unter x86_64 32 bit Anwendungen (Java etc.) benötigt installiert sich die $PAKET-32bit Versionen.
Wer seinen 64bit CPU als 32bit laufen lassen will nimmt sowieso das i386 Repository.
Oder konkret gefragt: unter welchen Umständen wird jemand die glibc-2.4-31_i686 aus dem x86_64 Rep. installieren wollen?
 
panamajo schrieb:
(ich ging fälschlicherweise davon aus dass mit SUSE 10.1 die -32bit Pakete gegen i586 ersetzt wurden).
Wurden sie auch, aber nur teilweise.

Bei der glibc geht das nicht (glibc-32bit.x86_64 kann nicht nur glibc.i686 ersetzt werden), weil glibc-32bit.x86_64 und glibc.i686 wirklich verschieden sind. Die glibc-Pakete enthalten nicht nur Bibliotheken, sondern auch Programme (/sbin/ldconfig, /usr/bin/ldd etc.), deswegen kann man glibc.x86_64 und glibc.i686 nicht gleichzeitig installieren, weil die Programme sich überlappen würden. Deswegen gibt es glibc-32bit.x86_64, welches sich von glibc.i686 durch den kleinen, aber feinen Unterschied abhebt, dass die Programme nicht enthalten sind, sondern nur die Bibliotheken.
panamajo schrieb:
Mir ist trotzdem nicht klar welchem Zweck die i[56]86 Pakete dienen sollten:
Wer unter x86_64 32 bit Anwendungen (Java etc.) benötigt installiert sich die $PAKET-32bit Versionen.
Bei einigen Paketen muss man auf x86_64-Systemen die ix86-Versionen nehmen, z.B. bei OpenOffice_org und MozillaFirefox, weil es da einfach kein entsprechendes x86_64-Paket gibt. Aber bei der glibc gilt das nicht, weil die glibc-Pakete - wie bereits ausgeführt - als *-32bit.x86_64-Variante vorliegen.
 

emoenke

Member
traffic schrieb:
Die 32-Bit-glibc kommt nicht aus einem i686-Paket (glibc.i686), sondern aus einem x86_64-Paket (glibc-32bit.x86_64).

OK, dann werfe ich jetzt versuchsweise alles mit i686 im Namen raus.

Aber bitte gleich meckern hier, wenn das Nebenfolgen hat! Keinen neuen Thread damit aufmachen, sonst sehe ich es erst später.
 
i686 rauswerfen sollte ungefährlich sein, weil das nur die Pakete glibc und db betrifft, die *-32bit-mäßig aufbereitet sind.

i586 rauswerfen kann Nebenwirkungen haben, weil OpenOffice_org und MozillaFirefox dann nicht mehr zugänglich wären.
 

emoenke

Member
Meiner bescheidenen Meinung nach sind für den 32bit Modus die -32bit Pakete zuständig, und diese sind ja auch weiterhin im Repository enthalten (ich ging fälschlicherweise davon aus dass mit SUSE 10.1 die -32bit Pakete gegen i586 ersetzt wurden).
Mir ist trotzdem nicht klar welchem Zweck die i[56]86 Pakete dienen sollten:
Wer unter x86_64 32 bit Anwendungen (Java etc.) benötigt installiert sich die $PAKET-32bit Versionen.
Wer seinen 64bit CPU als 32bit laufen lassen will nimmt sowieso das i386 Repository.
Oder konkret gefragt: unter welchen Umständen wird jemand die glibc-2.4-31_i686 aus dem x86_64 Rep. installieren wollen?

Do solltest nicht von glibc auf alles andere schliessen, sondern lieber z.B. von acroread.

Es ist völlig klar, daß es zerstörerisch wäre, auch i586 auszublenden.
 

emoenke

Member
traffic schrieb:
i686 rauswerfen sollte ungefährlich sein, weil das nur die Pakete glibc und db betrifft, die *-32bit-mäßig aufbereitet sind.

i586 rauswerfen kann Nebenwirkungen haben, weil OpenOffice_org und MozillaFirefox dann nicht mehr zugänglich wären.

Der i686-Rauswurf erstreckt sich natürlich auch z.B. auf Packman.
Also weiß jetzt hoffentlich JEDER hier, daß es Nebenwirkungen gibt, wenn einzelne User zu faul zum Pinnen sind.

Aber ich hätte es vorher wissen müssen: Serving fools only creates a new fool.

Jetzt löffelt die Suppe erstmal aus, die ihr bestellt habt, und dann sehen wir, ob's Dünnschiß davon gibt.
 
emoenke schrieb:
Aber ich hätte es vorher wissen müssen: Serving fools only creates a new fool.
Wow, nicht schlecht, Herr Specht.

emoenke, die i686-Pakete von PackMan sind aber sowas von x86_64-untauglich, das ist echt kein Verlust. Und i586 übrigens auch - die von PackMan meine ich.
emoenke schrieb:
Jetzt löffelt die Suppe erstmal aus, die ihr bestellt habt, und dann sehen wir, ob's Dünnschiß davon gibt.
Autsch.
 

oc2pus

Ultimate Guru
hey Jungs, das Thema ist zu spannend um damit in Streitereien und Kraftausdrücke zu verfallen ...

das habt ihr auch nicht nötig, oder :mrgreen:
also zurück zu sachlichen klaren Fakten. So wie ich es von euch gewohnt bin....
 

emoenke

Member
traffic schrieb:
emoenke, die i686-Pakete von PackMan sind aber sowas von x86_64-untauglich, das ist echt kein Verlust. Und i586 übrigens auch - die von PackMan meine ich.

Ich rätsele und rätsele, und ich komme nicht drauf, wo der ernstgemeinte Kern sein könnte.

Wenn ich in meinen x86_64-Systemen ganz i586 und i686 von Packman weglasse, kann ich weder TV gucken oder aufzeichnen, noch DVDs gucken oder hören, und reines Audio ist auch nicht mehr gut genug.
 

emoenke

Member
oc2pus schrieb:
hey Jungs, das Thema ist zu spannend um damit in Streitereien und Kraftausdrücke zu verfallen ...

das habt ihr auch nicht nötig, oder :mrgreen:
also zurück zu sachlichen klaren Fakten. So wie ich es von euch gewohnt bin....

Oh, welch' Kompliment. Danke für die Zurückhaltung. ;-))

Nach dem naechsten aptate in ftp4 wird's wirklich spannend. In etwa einer Stunde geht's los...
 
emoenke schrieb:
Ich rätsele und rätsele, und ich komme nicht drauf, wo der ernstgemeinte Kern sein könnte.
MPlayer.x86_64 unterstützt keine Windows-Codecs. MPlayer.ix86 unterstützt sie sehr wohl, braucht aber x264.ix86. vlc.x86_64 braucht aber x264.x86_64. x264.x86_64 und x264.ix86 gleichzeitig installieren geht nicht, weil es einen Zusammenstoß mit /usr/bin/x264 gibt. Lösung: x264-32bit.x86_64 ohne /usr/bin/x264. Gibt's aber leider nicht.

Ausweichen auf vlc.ix86 würde im Hinblick auf x264.ix86 gehen, geht aber am Ende trotzdem nicht, weil wxGTK-32bit.x86_64 fehlt. wxGTK.ix86 sieht vielleicht nett aus, zieht aber aMule.x86_64 auf aMule.ix86 runter. Und das geht auch wieder nicht, weil gd-32bit.x86_64 fehlt. gd.ix86 kann man stattdessen leider nicht nehmen, weil das wieder Zusammenstöße in /usr/bin mit gd.x86_64 gibt.

Ach, bevor der Eindruck entsteht, irgendwer hätte hier irgendetwas bestellt: Stimmt nicht, steht nirgends. Angenehmen Start ins Wochenende an alle (fools eingeschlossen).
 

emoenke

Member
traffic schrieb:
emoenke schrieb:
Ich rätsele und rätsele, und ich komme nicht drauf, wo der ernstgemeinte Kern sein könnte.
MPlayer.x86_64 unterstützt keine Windows-Codecs. MPlayer.ix86 unterstützt sie sehr wohl, braucht aber x264.ix86. vlc.x86_64 braucht aber x264.x86_64. x264.x86_64 und x264.ix86 gleichzeitig installieren geht nicht, weil es einen Zusammenstoß mit /usr/bin/x264 gibt. Lösung: x264-32bit.x86_64 ohne /usr/bin/x264. Gibt's aber leider nicht.

Ausweichen auf vlc.ix86 würde im Hinblick auf x264.ix86 gehen, geht aber am Ende trotzdem nicht, weil wxGTK-32bit.x86_64 fehlt. wxGTK.ix86 sieht vielleicht nett aus, zieht aber aMule.x86_64 auf aMule.ix86 runter. Und das geht auch wieder nicht, weil gd-32bit.x86_64 fehlt. gd.ix86 kann man stattdessen leider nicht nehmen, weil das wieder Zusammenstöße in /usr/bin mit gd.x86_64 gibt.

Ich wette, Du hast trotz dieser gezielt fatalistischen Darstellung der kleinen Problemchen Packman-Pakete mit drin.
 

emoenke

Member
traffic schrieb:
Ach, bevor der Eindruck entsteht, irgendwer hätte hier irgendetwas bestellt: Stimmt nicht, steht nirgends.

Nix da. Es wird nicht gekniffen jetzt.
Um 17:30 Uhr etwa verschwinden alle i686-Pakete aus dem 10.1-Repository für x86_64.

Da geht's jetzt geradeaus durch, und frühestens danach wird's wieder rückgängig gemacht.
 
emoenke schrieb:
Nix da. Es wird nicht gekniffen jetzt.
Niemand kneift hier. Sich dagegen zu wehren, dass Dinge in den Mund gelegt werden, die nie gesagt wurden, hat aber auch wirklich gar nichts mit Kneifen zu tun.

Langsam aber sicher wird's hier unangenehm emotional => Servus!
 

emoenke

Member
traffic schrieb:
Sich dagegen zu wehren, dass Dinge in den Mund gelegt werden, die nie gesagt wurden, hat aber auch wirklich gar nichts mit Kneifen zu tun.

Das kann ja wohl jeder unterschreiben.
Du scheinst am Ende des Threads schon den Anfang vergessen zu haben. Macht aber nichts, es ist ja noch alles zu lesen.
 
Oben