Assarbad schrieb am 11.07.2017 19:38:
Also nix für ungut, aber bsdutils sehe ich persönlich durchaus als ein unabdingbares Paket an.
Na, ich weiß nicht: Sind doch ohnehin nur ziemlich harmlose Kommandos
$ dpkg -L bsdutils | grep -E '/(bin|lib)/' | fmt -w72
/usr/bin/logger /usr/bin/renice /usr/bin/script /usr/bin/scriptreplay
/usr/bin/wall
Und von denen hängt überhaupt nur ein einziges tatsächlich vom systemd ab:
$ ldd `dpkg -L bsdutils | grep -E '/bin|lib/'` 2> /dev/null | sed '/^\// h; /systemd/ !d; g; s/:$//'
/usr/bin/logger
Zweifellos deshalb, weil sich journald "natürlich" zu gut ist seine Log-Meldungen von /dev/log entgegen zu nehmen wie es jeder andere Logger macht.
Statt dessen tritt er, wie bei Poettering-Tools üblich, vorsätzlich alle bisherigen Konventionen mit Füßen, und erwartet seinen Socket für die Log-Meldungen irgendwo anders.
Daher musste auch "logger" gepatcht werden, damit es den Socket von journald finden kann.
Weiters nehme ich an dass Poettering irgendwo dokumentiert hat dass "niemand außer der systemd-Library" wissen könne wo der Log-Socket tatsächlich läge, so dass man den Wert nicht einfach hart in logger hinein patchen könne weil er mittels systemd-Config-Files konfigurierbar ist.
Ebenso würde systemd in seiner grenzenlosen Flexibilität nicht nur UDP-Sockets, sondern würde mittels irgend eines wunderbaren Plugin-Konzepts auch beliebige andere Methoden unterstützen wie Log-Meldungen übermittelt werden können.
Daher sei es unumgänglich, log-Meldungen überhaupt nicht mehr selbst auf irgend eine bestimmte Art und Weise abzusetzen, sondern statt dessen eine Funktion in der systemd-Library aufzurufen, da diese als einzige über alle Konfigurationsinformationen des lokalen Systems verfügen würde!
So ähnlich hat er garantiert argumentiert - und die bsdutils-Maintainer haben das "eingesehen" (= sich von ihm über den Tisch ziehen lassen wie so viele andere), und daher hängt "logger" in den bsdutils nun ebenfalls von der systemd-Library ab.
Ich *wette* aber, dass man das mit einem #define in den Quelltexten von bsdutils selektiv auswählen kann. Falls es sich bei dem systemd-Support nicht ohnehin um einen nachträglich hinzu gefügten Patch handelt.
Weil früher hat "logger" ja auch nicht die systemd-Library gebraucht.
Zumal es unter BSD, woher die bsdutils ja vermutlich ursprünglich stammten, garantiert keinen systemd gibt!
Somit sollte es reichen, bsdutils mit anderen -D Optionen neu zu kompilieren, oder beim Bauen einfach einen Patch wegzulassen den die bsdutils-Maintainer für optionalen systemd-Support beim Bauen bereit stellen.
Obwohl, *ganz* verstehe ich die Erfordernis der systemd-Library trotz der obigen Argumentation immer noch nicht:
Das würde nur gelten wenn logger die Log-Meldungen früher direkt nach /dev/log geschickt hätte.
Aber eigentlich gibt es zum Verwenden von log-Meldungen ja standardisierte POSIX-Funktionen in <syslog.h> - man sollte annehmen dass "logger" diese einfach verwenden würde.
Und dass dann die systemd-Abhängigkeit wenn schon überhaupt, dann in der libc enthalten wäre.
Aber einen Verdacht habe ich schon, wie es vielleicht zu dem derzeitigen Zustand kam: Die Maintainer der glibc könnten Poettering eine Absage erteilt haben, als er sein Ansinnen vorbrachte die glibc solle intern doch bitte die systemd-Libary zur Implementation der POSIX <syslog.h>-Funktionen aufrufen anstatt die Log-Meldungen direkt nach /dev/log zu schreiben.
Statt dessen werden die glibc-Maintainer ihm etwas gehustet haben, in der Art "/dev/log ist Standard, warum sollten wir das ändern" und "Wir wollen die libc nicht von der libsystemd abhängig machen, die ist erstens zu fett und zweitens rechnet niemand damit dass die libc plötzlich zusätzliche Library-Abhängigkeiten bekommt nachdem sie Jahrzehnte lang keine hatte".
Darauf hin wette ich Poettering hat ihnen angeboten den Code der systemd-Library einfach direkt in die glibc aufzunehmen. Dann könnte es eine einzelne Library bleiben. Worauf hin die glibc-Maintainer vermutlich so etwas antworteten wie: "Ist dir noch ganz wohl? Wegen einer popeligen log-Funktion sollen wir eine Library statisch dazu linken, die halb so groß wie die ganze bisherige libc selbst ist? NEIN DANKE!"
Nach dieser Absage hatte Poettering also 2 Möglichkeiten: Er hätte aufgeben können und /dev/log benutzen wie jeder andere.
Aber so etwas kommt bei ihm natürlich nicht in Frage.
Statt dessen bequatschte er die bsdutils-Maintainer offensichtlich erfolgreich, und beschwor zweifelsohne Schreckensbilder von Heerscharen tränenschluchzender systemd-Benutzer vor deren geistigem Auge, welche alle ganz verbittert wären und den bsdutils-Maintainer schreckliche Vorwürfe machen würden, wenn die Meldungen von "logger" nicht ihren Weg zu journald finden würden.
Angstschlotternd dem großartigen technischen Fortschritt von systemd nicht im Wege stehen zu wollen, bauten die bsdutils-Maintainer daher die systemd-Library-Abhängigkeit in "logger" ein.
Und Poettering rieb sich (wieder einmal) die Hände.
Bei allen Hass auf systemd meine ehrliche Bewunderung: Der Mann ist wirklich ein genialer Stratege und Taktiker.
Er versteht es geschickt, die Maintainer verschiedene Pakete gegen einander auszuspielen, so dass am Ende überall systemd hinein muss weil es "alternativlos" sei.
Poettering wäre zweifelsohne ein guter General in irgend einer Armee bei derer Eroberungs-Feldzügen.
Aber leider verwandelt er statt dessen unser gutes Linux in ein Schlachtfeld, und das finde ich kein bisschen Lustig.
Gemessen am verursachten Zwist und unnötig zerschlagenem Porzellan innerhalb der Community hat Poettering bereits heute viel mehr Schaden angerichtet, als es Microsoft mit ihren miesesten (damaligen) Marketing-Hetzkampagnen gegen Linux jemals geschafft haben.
Denn wo Balmer mit dem Holzhammer von außen auf Linux eingeprügelt hat, vergiftet Poettering Linux von innen her. Und das sehr geschickt, ohne dass es all zu offensichtlich wird.
Falls eines Tages publik werden sollte dass Poettering in Wahrheit der uneheliche Sohn von Stephen Elop ist - es würde mich nicht wundern.