Debian runs out of a systemd maintainer due to disagreements

Debian-with-systemd

Michael Biebl, who has been involved in Debian development since 2004 and which is one of the main contributors to the distribution of in the system manager area "systemd", left the package to Debian.

This was because as maintainer from the systemd package, has described the situation with the correction of the system errors as "stupid and insane", and promising not to send bug reports to system developers again.

What caused this?

The conflict arose due to the appearance of a regressive change in the version of systemd 240, which caused behavior changes when processing existing udev rules and problems for Debian users when changing the renaming logic of network interfaces.

Despite using “NAME” option to bind network interface name to MAC address after transition in udev from systemd 240.

The network interfaces of the Ethernet adapters changed their names from fixed to auto-generated (previously the replacement was done only once, and since version 240 it can be used) There are several replacements).

Michael Bibl asked the systemd developers to revert to previous behavior when manual name binding specified in config is of higher priority.

That's a regression compared to v239, and I am inclined to add it to the v241 milestone as it may mean the loss of network access. Argument Michael Bibl

However the systemd developers did not consider this regressive change to be a problem, as changes made to systemd 240 did not violate the documented behavior, undocumented udev features were used, the performance of which was not guaranteed.

Debian

However, later evidence was found that the above behavior is described in the documentation.

That was how Yu Watanabe, replied, basically saying it wasn't something that affected:

Why is lan0 called when the driver loads? Yes, the end result is, ens3, then I hope it is always ens3.

What Michael Bible he replied:

It should always be named lan0 because of the udev rule.

The problem was escalating

Thereafter, systemd developers suggested that the new behavior be selectively disabled.

In case udev rules are created for older versions of systemd (if the naming scheme is defined for versions less than 240, set the option RenameOnce = yes by default, otherwise RenameOnce = no).

On the systemd developers mailing list, there was also a discussion about the proposal to issue, without further ado, fixes of systemd with fixes for serious bugs appearing in major versions.

Lennart Pottering rejected the idea, citing a lack of resources. TThe opinion was perceived by some developers as a fundamental misconception, as the priority focus on developing functionality to the detriment of stability has a negative effect on users.

In response, Lennart He referred to the fact that end users do not use the latest versions of systemd, but use packages stabilized by distributionsFor example, they are checked against Fedora and the QA service before placing system components on RHEL.

Before this Michael Bible, argument It does affect users, as this can create conflicts with the configurations already preset by the user in the system:

It is not better for users as it breaks existing user settings. What is it bad

In the case of shifting priorities in development and bug fixes in Lennart's view, only a generation of different criteria will emerge, in which bugs associated with exotic architectures, atypical graphics environments, libraries, and drivers will often be ignored and relegated to the community.

If you want to know a little more about the problem, you can follow up In the following link.


Leave a Comment

Your email address will not be published. Required fields are marked with *

*

*

  1. Responsible for the data: Miguel Ángel Gatón
  2. Purpose of the data: Control SPAM, comment management.
  3. Legitimation: Your consent
  4. Communication of the data: The data will not be communicated to third parties except by legal obligation.
  5. Data storage: Database hosted by Occentus Networks (EU)
  6. Rights: At any time you can limit, recover and delete your information.

  1.   luix said

    Once again I say it: systemd sucks !!