Debian pozostaje bez opiekuna systemd z powodu nieporozumień

Michael Biebl, który jest zaangażowany w rozwój Debiana od 2004 roku i która jest jeden z głównych współpracowników do dystrybucji w obszarze zarządzania systemem "systemd" zostawił pakiet Debianowi.

To dlatego, że jako opiekun z pakietu systemd, opisał sytuację z korektą błędów systemowych jako „głupią i szaloną”, i obiecując, że nie będziemy ponownie wysyłać raportów o błędach do programistów systemu.

Co to spowodowało?

Konflikt powstały w związku z pojawieniem się regresywnej zmiany w wersji systemd 240, que lo spowodował zmiany w zachowaniu podczas przetwarzania istniejących reguł udev i problemy użytkowników Debiana przy zmianie logiki zmiany nazw interfejsów sieciowych.

Pomimo użycia opcji „NAZWA” do powiązania nazwy interfejsu sieciowego z adresem MAC po przejściu udev z systemd 240.

Interfejsy sieciowe adapterów Ethernet zmieniły nazwy ze stałych na generowane automatycznie (poprzednio wymiana była wykonywana tylko raz, a od wersji 240 można jej używać). Istnieje kilka zamienników).

Michael Bibl poprosił programistów systemd o przywrócenie poprzedniego zachowania, gdy ręczne wiązanie nazw określone w konfiguracji ma wyższy priorytet.

To regresja w porównaniu z wersją 239 i jestem skłonny dodać ją do kamienia milowego wersji 241, ponieważ może to oznaczać utratę dostępu do sieci. Argument Michael Bibl

Pero programiści systemd nie uznali tej regresywnej zmiany za problem, ponieważ zmiany wprowadzone w systemd 240 nie naruszały udokumentowanego zachowania, użyto nieudokumentowanych funkcji udev, których działanie nie było gwarantowane.

Jednak później znaleziono dowody, że powyższe zachowanie jest opisane w dokumentacji.

Oto jak - odpowiedział Yu Watanabemówiąc zasadniczo, że to nie miało wpływu na:

Dlaczego jest wywoływana lan0 podczas ładowania sterownika? Tak, efekt końcowy to ens3, mam nadzieję, że zawsze będzie to ens3.

Co Michał Biblia odpowiedział:

Ze względu na regułę udev powinien zawsze nazywać się lan0.

Problem narastał

Po tym Twórcy systemd zasugerowali, aby nowe zachowanie zostało selektywnie wyłączone.

W przypadku, gdy reguły udev są tworzone dla starszych wersji systemd (jeśli schemat nazewnictwa jest zdefiniowany dla wersji mniejszych niż 240, ustaw opcję RenameOnce = tak domyślnie, w przeciwnym razie RenameOnce = no).

Na liście mailingowej deweloperów systemd była też dyskusja na temat propozycji wydania, bez zbędnych ceregieli, poprawki systemd z poprawkami poważnych błędów pojawiających się w głównych wersjach

Lennart Pottering odrzucił ten pomysł, powołując się na brak zasobów. TOpinia ta została odebrana przez część deweloperów jako fundamentalne nieporozumienie, gdyż priorytetowe skupienie się na rozwoju funkcjonalności ze szkodą dla stabilności ma negatywny wpływ na użytkowników.

W odpowiedzi Lennart Odniósł się do faktu, że użytkownicy końcowi nie korzystają z najnowszych wersji systemd, ale korzystają z pakietów stabilizowanych przez dystrybucjeNa przykład są one sprawdzane pod kątem Fedory i usługi QA przed umieszczeniem komponentów systemu w RHEL.

Przed tym Michała Biblię, argument Ma to wpływ na użytkowników, ponieważ może to powodować konflikty z konfiguracjami już ustawionymi przez użytkownika w systemie:

Nie jest to lepsze dla użytkowników, ponieważ łamie istniejące ustawienia użytkownika. Co to jest zły

W przypadku zmiany priorytetów w rozwoju i poprawkach błędów w opinii Lennarta, pojawi się tylko generacja różnych kryteriów, w których błędy związane z egzotycznymi architekturami, nietypowymi środowiskami graficznymi, bibliotekami i sterownikami będą często ignorowane i przenoszone do społeczności.

Jeśli chcesz dowiedzieć się więcej o problemie, możesz kontynuować W poniższym linku.