Today I performed quite a lot of updates on my gentoo system, i.e. udev and mysql.

Because mysql-libraries are built-in into many packages I started revdep-rebuild directly after the updates. Unfortunately some services stopped working afterwards: My whole mail-system wouldn’t work.
Fyi: I use a combination of fetchmail/postfix/clamav/spamd/procmail for local maildelivery and dovecot/imap as mailcontainer.
The short version is: The new udev shuffled my network devices. I had to reassign the correct IP-configs to the accordant cards. The dovecot and postfix binaries were broken because they depended on old mysql libs. Obviously revdep-rebuild is not sufficient in all cases. A simple emerge dovecot postfix worked finally.
Because of the strange combination of device and service problems I had some work for discovering the real matter.

Edit (01.12.2006):

Two days after this post the udev-update was dicussed in the gentoo-dev mailinglist. Now I know the reason for the shuffled network-devices. Before you could determine the order of the network devices by loading them via modprobe.d. Now udev does it’s work before modules.d.
The recommended way to influence the interfaces’ order is udev’s interface renaming capability.

See http://www.reactivated.net/writing_udev_rules.html#example-netif

Nun endlich befasse ich mich mit einem Fehler beim emerge -uvDa world, den ich einige Zeit vor mir her geschoben habe.

Beim Versuch des Updates kommt nach dem Entpacken der Patchfiles zuerst eine Mitteilung:

This version no longer provides compatibility with old broken applications. If you need this support, dcall your vendor and tell them to release an update that isn’t broken.
Danach direkt die Fehlermeldung:

!!! Error: sys-libs/glibc-2.4-r4 failed.
Call stack: […]
!!! non-TLS symbol errno@glibc_2.0 not supported
!!! if your need support, post the topmost build error, and the call stack if relevant.

Nach einigem Probieren bemerkte ich, dass dem ebuild der neuen glibc-Version ein neues USE-Flag namens glibc-compat20 zugefügt wurde. Genau dieses USE-Flag wird auch in einer der im Call Stack aufgeführten Zeilen im Ebuild abgefragt.

Ich habe mich nicht tiefer in das Ebuild eingelesen, aber beim groben überlesen machte es den Eindruck, als würde bei diesem gesetzten USE-Flag einfach die oben erwähnte Fehlermeldung ausgegeben und der Merge-Vorgang abgebrochen.

Nachdem ich dieses USE-Flag deaktiviert hatte, lief auch das Update problemlos.
Warum scheint dieses Flag so völlig frei von Funktion zu sein? Und wenn es schon lediglich einen Abbruch des Merges bewirkt - warum war es dann nach Einführung direkt standartmäßig aktiviert?

Es scheint mit der gewählten Art der verwendeten Threads zusammen zu hängen. TLS wird auch hier und da erwähnt. Vielleicht finde ich bei Gelegenheit mehr über dieses Thema heraus.

Vor zwei Wochen entschieden sich die Gentoo-Entwickler den alt bekannten Mediaplayer XMMS aus dem Portage Tree zu entfernen. Über die Hintergründe wird viel diskutiert und auch spekuliert. Offensichtlich lag die endgültige Entscheidung an der nach wie vor großen Anzahl von bekannten schwerwiegenden Bugs beim XMMS. Seit Jahren lag die Software ohne erkennbare Wartung herum. Anstatt die Bugs zu beheben wurde seit Jahren schon eine Nachfolgeversion XMMS2 angekündigt, die bis heute allerdings nicht erschienen ist.

Nun bleibt es dem Nutzer überlassen, ob er weiterhin mit seinem gewohnten WinAmp-Klon arbeiten oder lieber doch auf eine besser Unterstützte Software umsteigen möchte. Der Vorteil des Gentoo-Konzeptes ist ja, dass maskierte Ebuilds demaskiert und entfernte Ebuilds im Portage-Overlay am Leben gehalten werden können (genau genommen wurde XMMS vorerst ja nur maskiert).
Ob die Weiternutzung einem schlichten Anwender allerdings zuzuraten ist, wage ich zu bezweifeln. Immerhin wendeten die Gentoo-Entwickler in den letzten Jahren einen nicht unerheblichen Teil ihrer Arbeit dafür auf, dieses verbuggte Stück Software überhaupt innerhalb ihrer Distribution lauffähig zu halten. Diese Arbeit wird in Zukunft nicht mehr übernommen.
Stellt sich die Frage, ob bei einem Erscheinen des XMMS2 dieser tatsächlich wieder in den Tree aufgenommen wird.

Der arbeitsscheue Anwender sieht sich also nach Alternativen um. Da wären zuerst die GTK2-Ports und sonstigen Derivate des XMMS, wie der Beep Media Player oder audacious.
Leider muss ich berichten, dass diese beiden sich auf meinem System installieren ließen, aber beim Start direkt abstürzten. Also wagte ich mich doch einmal experimentiell weg vom gewohnten Look.

Meine Wahl fiel auf amaroK. Dieser Player ist ein richtiggehendes Audio-Center. Statt der bisher bekannten einfachen Playlist (die man beim XMMS allerdings meiner Meinung nach sehr schön durchsuchen konnte) wird die Musiksammlung übersichtlich nach Interpreten und deren Alben sortiert angeboten. Optional holt amaroK CD-Covers, Liedertexte und Infos über die Interpreten aus dem Internet und blendet sie in der sogenannten Kontext-Ansicht ein. Die Möglichkeit, Visualisierungsplugins einzubinden, habe ich nicht mit einkompiliert. Schade nur, dass amaroK ein reiner Musikplayer ist. So werde ich zum Ansehen von Filmen wohl beim guten soliden mplayer bleiben. Angeblich kann amaroK zwar problemlos die Tonspur von Videodateien abspielen, bei mir endeten diese Versuche früher oder später aber immer in einem Absturz.

Alles in Allem bleibt zu sagen, dass ich den Verlust eines lange gewohnten Players zwar bedauere, mich aber auch relativ schnell an die neue Situation gewöhnt habe. Und wer will schon auf völlig verbuggter und veralteter Software sitzen bleiben…