Hi Ansgar,
On 7/11/24 06:15, Ansgar ๐ wrote:
It is supported *now*, but the roadmap is unclear -- that support could
be discontinued at any moment, and it would not be the first time a
feature Debian relied on was removed.
I understand your fears about the uncertainty of future developments.
No, you don't.
What I'm concerned about is not packages as a whole being discontinued.
This is highly unlikely for systemd, and for simpler packages, it is not
a problem as long as we are able to react to security issues.
My concern is *interfaces* and *features* being discontinued in new
versions, requiring adaptation on our end before we can update a package
that we want to upgrade. Specifically I'm looking at the interface for
passing in system-wide network configuration, because that interface
will likely stand in the way of future systemd-networkd development:
1. Plain text files with passwords in them are "unix-like", and systemd
has a builtin credential store mechanism, systemd-creds. I expect that
there will be a bit of push to move things like passwords into the
credential store (which is unavailable from the d-i environment).
2. So far, systemd-networkd does not support run-time configuration from
unprivileged accounts (so on laptops it makes sense to keep using N-M).
I am not convinced that there are no plans to add that feature though,
and at that point, the configuration and credential storage will need to
be reworked.
This is why I think that this interface will be considered a liability
down the line by upstream developers. It's what I would do in their place.
After all ifupdown is without doubt in a bit problematic state due to
isc-dhcp-client no longer being supported, a feature Debian relied on,
and as far as we know the support for alternatives like dhcpcd-base
could end at any time as well.
That is not a feature, but a package. Unless we actively remove it, it
stays. The thing that is special about systemd is that they actively
remove things that are in the way of future progress, such as support
for unmerged /usr, and we need to deal with that whenever it happens.
That is not a fault either: it costs resources to keep legacy interfaces
working, and with the ambitious feature set they have, those are better
spent elsewhere, but whenever we rely on a legacy interface, we need to
be prepared to have it pulled out at some point, like the unit generator
for init scripts.
Debian already relies on a fairly large set of base software like gcc,
linux, glibc, systemd, ... So it seems reasonable to try to not grow
that list much further to address your concerns.
Linux and glibc are going to great lengths to never break compatibility
during an upgrade, these are full of compatibility code. GCC we use an
older version that we do not upgrade during a release, and we get full
support from upstream for that. The experience of reporting a bug
against gcc 12 is vastly different from reporting a bug against systemd 252.
Again, that is not a fault, but a difference in project management --
but one that we need to account for when we are doing our own planning.
The more policy work we outsource to external projects that work at a
faster pace than we do, the more resources we need to keep on hand to
catch up. This is not a technical problem, but a project management one.
The technical aspects of this are the easy part, although it is also
possible to bungle them if they are left to overconfident people.
Simon
