The motivation is that variants of the same distro that share the same compiled
rpm want to customize various aspects of the system, in particular the
hostname. In some sense the default hostname is part of the identity of the
system, so setting it through os-release makes sense. In particular, instead of
setting a default value in /etc/hostname, the appropriate default can be baked
into the image, leaving /etc/hostname for local overrides only.
Why make this a separate field instead of e.g. using NAME from os-release?
NAME is already used for other purposes, and it seems likely that people want
to set those independently.
e3820eeaf1 did that replacement XDG_CONFIG_HOME, in one
of two places. Let's use ~/.config everywhere.
Quoting https://github.com/systemd/systemd/pull/18704#discussion_r579465254:
> I'd really drop XDG_CONFIG_HOME from the docs. It's confusing enough as it
> is. Where we don't need the indirections we should not confuse people with
> it, in particular as people might then think it's actually a good idea to use
> that env var and redirect things. I'd just show the literal path everywhere,
> even if we internally use the env var.
This is useful for various variables that modify process behaviour. This makes
it easy to set it for pid1 without touching the kernel command line. Even for
the *user manager* this also can be convenient for the unprivileged user, who
cannot modify user@.service definition.
Variables that could be set like this include $SD_EVENT_PROFILE_DELAYS,
$SYSTEMD_FALLBACK_HOSTNAME, $SYSTEMD_MEMPOOL, $SYSTMED_RDRAND, etc.
This changes the paths we read user manager config from in two ways:
- split-usr-root paths are dropped. The user manager is a poster boy for
non-early-boot, so reading dropins only from /usr is appropriate.
- we look at ~/.config/systemd/user.conf. Users should be allowed to override
their own config.
As user managers become more and more used, it becomes more important for users
to customize their own daemon. By reading from ~/.config, this is possible
without privileges.
The additional rules fix a firmware bug in the en keyboard of Librem notebooks by Purism.
By doing so the break the keyboard with other layouts which do not have the same bug in their firmware.
This doesn't really change anything, but feels nicer, since it abstracts
away what device_action_from_string()/device_action_to_string() do
internally, and always uses a normalized action string (yes, there's no
ambiguity, but it's nice to stay abstract, maybe one day there is
ambiguity around this)
To make sd-device properly usable for all programs we need to provide an
API for the "action" field of an event, it's one of the most relevant
ones, and it was so far missing.
This also adds sd_device_get_seqnum(), which isn't that interesting,
except for generating pretty debug output, which we use it ourselves
for.
This also makes device_new_from_stat_rdev() public, as it is truly
useful, as we can see in our own uses of it, and I think is fairly
generic to show up in the public APIs.
Apparently, in our current public headers (i.e. those called sd-*.h) we
suffixed typedefs that we use as values with _t, but we didn't do this
for enum typedefs. Fix that while this stuff is not actually public yet.
With this scheme "value typedefs" now end systematically in _t, and
"object typedefs" (i.e. structures that are typically passed around via
pointers and not values) do not.
No code changes, just some renaming.
Fragmenting sucks, let's avoid it. Thus let's start tracking the maximum
fragment size we receive.
Also, let's redo a transaction via TCP if we see fragmenting on UDP, as
effective mitigation against DNS fragment attacks.
