control: retitele -1 provide fair warning to Bug1112535-like situation control: severity -1 wishlist thanks
Hi, Thanks for the reminder. I see 4 references to systemd-networkd feature. Please note I use "MAY". So it is presented as optional feature. Disclaimer: I am only following systemd-networkd(8) documentation to write this section. I don't use this feature. As I read mentioned bug report #1112535, Luca doesn't mention his rationale for his "EXPERIMENTAL" judgment. I don't think this bug title "maintainer insists systemd-networkd not to be used" is fair characterization for discussion with Luca. Since upstream systemd doesn't say "EXPERIMENTAL" for the systemd-networkd feature, it is in reasonable shape by itself, I suppose. I understand Luca may call use of systemd-networkd as "EXPERIMENTAL" from system integration perspective because it changes such a fundamental system component which is setup by debian-installer from "Debian system" perspective. Unlike bash-to-dash or usr/bin-merge, this is not on the table for migration and not tested for upgrade. I think it is wrong to press package maintainer and release manager for bug management. I can think of many similar alternative components with similar essential features (use of dracut-core instead of initramfs-tools). Upgrade robustness tend to become fragile. Also, it is impractical for package maintainer to guarantee upgrade stability. Fair warning somewhere for making wild system change from d-i installed state. Let me think how to address. Osamu On Tue, 2025-09-09 at 12:12 -0400, Kevin Otte wrote: > Source: debian-reference > Version: 2.127 > Severity: minor > > Dear Maintainer, > > Section 5.3 of the manual clearly outlines the usage of systemd-networkd for > non-GUI network configuration under Debian. > Its inclusion here indicates this is a supported mechanism. > > However, in #1112535 the systemd package maintainer, Luca Boccassi, insists > that systemd-networkd is an optional component, at one point even going so far > as to call it experimental. > > If Luca is correct and this is the case, the manual should be updated to > reflect this fact. > > If the manual is correct, as I believe it to be, Luca should be informed of > this and encouraged to issue a correction. > Many of us in the mentioned bug report have attempted to persuade him of this > to no avail. Perhaps you will have better luck.
