Et il a parfaitement raison de refuser ces patchs.
Ce qui est demandé par ces distributions n'a aucun sens, et c'est évident à n'importe qui comprenant de quoi il s'agit.
Accepter des patches de ce genre, cela signifie tout simplement d'accepter de maintenir une sorte de fork de glibc dans systemd. Parce que ces patches consistent à maintenir des fonctionnalités manquantes de musl-libc (par exemple) par rapport à glibc, dans systemd.
systemd n'a pas la vocation d'être une libc, c'est à musl-libc qu'il faut envoyer ces patches évidemment. Et bien sûr cela a été fait, mais qu'ont répondu ces différents libc ? Elles ont refusé !
Et évidemment, on essaie de porter le blâme sur systemd.
Pour le système de logs de systemd dans BusyBox, cela n'avait de toutes façons aucun sens, systemd venant avec son système de logs. En fait cela ne change rien en pratique.
[^] # Re: Musl / uclibc
Posté par ookaze . En réponse au journal Busybox retire le support de systemd ?. Évalué à 9.
Et il a parfaitement raison de refuser ces patchs.
Ce qui est demandé par ces distributions n'a aucun sens, et c'est évident à n'importe qui comprenant de quoi il s'agit.
Accepter des patches de ce genre, cela signifie tout simplement d'accepter de maintenir une sorte de fork de glibc dans systemd. Parce que ces patches consistent à maintenir des fonctionnalités manquantes de musl-libc (par exemple) par rapport à glibc, dans systemd.
systemd n'a pas la vocation d'être une libc, c'est à musl-libc qu'il faut envoyer ces patches évidemment. Et bien sûr cela a été fait, mais qu'ont répondu ces différents libc ? Elles ont refusé !
Et évidemment, on essaie de porter le blâme sur systemd.
Pour le système de logs de systemd dans BusyBox, cela n'avait de toutes façons aucun sens, systemd venant avec son système de logs. En fait cela ne change rien en pratique.