Debian остава без поддържащ systemd поради разногласия

Michael Biebl, който участва в разработката на Debian от 2004 г. и което е един от основните участници до разпределението на в областта на системния мениджър "systemd", оставете пакета на Debian.

Това беше така, защото като поддържащ от пакета systemd, е описал ситуацията с коригирането на системни грешки като "глупава и луда", и обещавайки да не изпраща отново доклади за грешки на разработчиците на системи.

Какво причини това?

Конфликтът възникна поради появата на регресивна промяна във версията systemd 240, като причинени промени в поведението при обработка на съществуващи правила udev и проблеми за потребителите на Debian при промяна на логиката на преименуване на мрежовите интерфейси.

Въпреки че използва опцията "NAME", за да обвърже името на мрежовия интерфейс с MAC адреса след udev прехода от systemd 240.

Мрежовите интерфейси на Ethernet адаптерите смениха имената си от фиксирани на автоматично генерирани (преди това замяната беше извършена само веднъж и от версия 240 може да се използва) Има няколко замени).

Michael Bibl помоли разработчиците на systemd да се върнат към предишното поведение, когато ръчното свързване на име, посочено в config, е с по-висок приоритет.

Това е регресия в сравнение с v239 и съм склонен да го добавя към етапа v241, тъй като това може да означава загуба на достъп до мрежата. Аргумент Майкъл Библ

Pero разработчиците на systemd не считат тази регресивна промяна за проблем, тъй като промените, направени в systemd 240, не нарушават документираното поведение, бяха използвани недокументирани udev функции, чието изпълнение не беше гарантирано.

По-късно обаче бяха открити доказателства, че горепосоченото поведение е описано в документацията.

Ето как Отговори Ю Ватанабе, основно казвайки, че това не е нещо, което е повлияло:

Защо се извиква lan0, когато водачът се зареди? Да, крайният резултат е, ens3, тогава се надявам, че винаги е ens3.

Какво Майкъл Библ той отговори:

Винаги трябва да се нарича lan0 поради правилото udev.

Проблемът ескалира

След това, разработчиците на systemd предложиха новото поведение да бъде селективно деактивирано.

В случай, че се създават udev правила за по-стари версии на systemd (ако схемата за именуване е дефинирана за версии под 240, задайте опцията RenameOnce = да по подразбиране, в противен случай RenameOnce = не).

В пощенския списък на системните разработчици имаше и дискусия относно предложението за издаване, без допълнителни шумове, поправя версии на systemd с поправки за сериозни грешки, появяващи се в основните версии.

Ленарт Потеринг отхвърли идеята, като се позова на липсата на ресурси. тСтановището се възприема от някои разработчици като основно заблуждение, тъй като приоритетният фокус върху разработването на функционалност в ущърб на стабилността има отрицателен ефект върху потребителите.

В отговор Леннарт Той се позова на факта, че крайните потребители не използват най-новите версии на systemd, а използват пакети, стабилизирани от дистрибуцииНапример те се проверяват спрямо Fedora и QA услугата, преди да поставят системните компоненти на RHEL.

Преди това Майкъл Библ, аргумент Това засяга потребителите, тъй като това може да създаде конфликти с конфигурациите, които вече са предварително зададени от потребителя в системата:

Не е по-добре за потребителите, тъй като нарушава съществуващите потребителски настройки. Какво е лошо

В случай на промяна на приоритетите в разработката и поправките на грешки в мнението на Lennart, ще се появи само поколение различни критерии, при които грешки, свързани с екзотични архитектури, нетипични графични среди, библиотеки и драйвери, често ще бъдат игнорирани и прехвърлени в общността.

Ако искате да научите малко повече за проблема, можете да продължите В следващия линк.