Repository als Ersatz für sys-apps/systemd-utils & Co.?

[guru meditation]

Kennt hier jemand ein externes Repository mit Ersatz für den Systemd und elogin-Kram? Früher lief Gentoo ja auch mit libpam, opentmp, und evdev.

Die alten Profile (17.1 oder so) sind ja nun "deprecated", und bevor ich dann gar nicht mehr aktualisieren kann, versuche ich das momentan…

[sMueggli]

Es gibt mehrere Threads im Forum von Leuten, die die gleichen ideologischen Einschränkungen umgesetzt haben wollen. Dort gibt es dann auch meistens Erklärungen zum Thema, warum und weshalb etwas so ist, wie es ist und welche Alternativen es gibt.

Und soweit ich weiss, hat das nichts mit dem genutzten Profil oder dessen Umstellung von 17.1 auf 23.0 zu tun. Die Aktualisierung des Profils sollte funktionieren, wenn man sich an die Anleitung (News-Item) hält.

[guru meditation]

Das Update auf 23 lief soweit recht flüssig. Allerdings will Portage nicht auf glibc 2.39 aktualisieren, weil andere Apps von der installierten 2.35 abhängig wären.

[sMueggli]

Wie hast du das dann gemacht? Gemäss News (https://www.gentoo.org/support/news-items/2024-03-22-new-23-profiles.html) in Schritt 1 muss glibc mindestens 2.36 sein:

[firefly]

[Max Steel]

Mit der Ausgabe von equery d sys-libs/glibc und eix sys-libs/glibc lässt sich das am ehesten herausfinden.
_________________
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)

[Josef.95]

Jo, ich denke keines der Pakete im aktuellen ::gentoo repo sollte eine hart maskierte glibc-2.35 Version als dep haben - wenn doch, dann wäre das ein Bug.
Die Ausgabe von

[guru meditation]

Das Problem mit Portage ist:

– Bei Upgrade von glibc über Drittpaket (namentlich shadow-4.14. verweigert emerge die Ausführung, weil angeblich zig Pakete von irgendwelchen alten glibc-Versionen abhängig seien. Das ist aber Quatsch, denn:

– Mit emerge -1 glibc aktualisiert Portage wiederum anstandslos auf die neue(ste) Version.

Nach einem Neustart erstellte Portage dann auch shadow anstandslos. Komich, nich?

[asturm]

Ohne irgendwelche logs sind jegliche Spekulationen Zeitverschwendung.

[Josef.95]

Puh ja, ohne dein verwendetes emerge Kommando zu kennen, und kein Stück Ausgabe gesehen zu haben, ist es schwierig dazu was zu sagen (da bleibt nur wildes raten und spekulieren).
Aber, klingt ein wenig danach als wenn versucht wurde nur einzelne Pakete, anstatt @world zu aktualisieren.
Falls ja, das geht selten gut - siehe dazu zb auch im https://wiki.gentoo.org/wiki/Project:Portage/FAQ#Why_is_there_a_dependency_conflict_when_I_attempt_to_upgrade_a_single_package.3F

[guru meditation]

Ich schrieb bereits, daß der Emerge @world öfters aussteigt, und beim zweiten Versuch haste dann Versionskonflikte (Slots). Sei es Open/LIbeSSL, teilweise ältere Versionen von Qt-Libs usw. Emerge beschwert sich also nur noch und macht nicht weiter. Manchmal (wie bei glibc) zieht sich Emerge auch angeblich „alternativlose“ Abhängigkeiten aus den Tiefen des digitalen Universums.

Aus diesem Grund speichere ich beim ersten Emerge eine Liste mit Paketen, die Portage aktualisieren würden. Steigt Portage mittendrin bei einem Paket mit Fehler aus, arbeite ich die Liste nach Problemlösung Paket für Paket weiter ab, notfalls mit dem --nodeps-Schalter, damit Portage mich mit seinen Versionskonflikten in Ruhe läßt. Auf die Tour läßt sich mich Portage mit seinem Konflikten in Ruhe und macht das Update fertig.

Mit dem Link werde ich auch mal
--ignore-built-slot-operator-deps=y
und
--backtrack=0
versuchen, vielen Dank.