vous pourriez aussi m'expliquer en quoi il y a besoin de forker pour proposer un init alternatif
Je pense que le problème, c'est que quand tu as des paquets qui dépendent de systemd pour certaines fonctionnalités, et que ces fonctionnalités sont utiles pour certains, ça va être difficile (et c'est normal) de convaincre ces mainteneurs pour qu'ils changent les options de compilation et/ou patchent le logiciel afin d'éliminer la dépendance ou proposer les deux options (ce qui peut compliquer la tâche au niveau des dépendances). Du coup, même si quelqu'un envoyait un patch pour proposer deux versions du paquet, ça ferait du travail en plus pour le mainteneur, de la communication en plus, des bugs en plus potentiellement, et il n'aura pas forcément envie de le faire. Du coup, il semble difficile de garantir, sans une ligne de conduite, une cohérence à une approche systemd+autres inits.
Bref, pour qu'une distribution marche, il faut une certaine harmonie, donc suivre certaines règles, et il convient de savoir pour un mainteneur s'il doit ou pas s'inquiéter de la dépendance ou non de ses paquets à un système d'init (mais la même question pourrait se poser pour d'autres choses, comme le noyau, la librairie C, compilateur utilisé pour compiler, etc.). Quand les règles ne conviennent pas à tout le monde, ça fait un fork qui survit s'il y a suffisamment de monde, ou juste meurt dans le cas contraire, mais en ayant au passage fait du bruit. En tous cas, il n'y a pas de solution qui juste marche et peut convenir à tout le monde, à certains moments il y a des choix compliqués, même (ou plutôt surtout) quand on veut être « universel » comme Debian.
[^] # Re: Trop facile résumé...
Posté par anaseto . En réponse au journal Pourquoi les zélateurs et détracteurs de systemd ne s'entendront jamais. Évalué à 3.
Je pense que le problème, c'est que quand tu as des paquets qui dépendent de systemd pour certaines fonctionnalités, et que ces fonctionnalités sont utiles pour certains, ça va être difficile (et c'est normal) de convaincre ces mainteneurs pour qu'ils changent les options de compilation et/ou patchent le logiciel afin d'éliminer la dépendance ou proposer les deux options (ce qui peut compliquer la tâche au niveau des dépendances). Du coup, même si quelqu'un envoyait un patch pour proposer deux versions du paquet, ça ferait du travail en plus pour le mainteneur, de la communication en plus, des bugs en plus potentiellement, et il n'aura pas forcément envie de le faire. Du coup, il semble difficile de garantir, sans une ligne de conduite, une cohérence à une approche systemd+autres inits.
Bref, pour qu'une distribution marche, il faut une certaine harmonie, donc suivre certaines règles, et il convient de savoir pour un mainteneur s'il doit ou pas s'inquiéter de la dépendance ou non de ses paquets à un système d'init (mais la même question pourrait se poser pour d'autres choses, comme le noyau, la librairie C, compilateur utilisé pour compiler, etc.). Quand les règles ne conviennent pas à tout le monde, ça fait un fork qui survit s'il y a suffisamment de monde, ou juste meurt dans le cas contraire, mais en ayant au passage fait du bruit. En tous cas, il n'y a pas de solution qui juste marche et peut convenir à tout le monde, à certains moments il y a des choix compliqués, même (ou plutôt surtout) quand on veut être « universel » comme Debian.