There were several modules, critically including NetworkManager, which
were not prepared for this change. Most of the change was good,
however. Let's bring back the dependency and change the assertion to a
warning for now.
Previously we required network-online.target for multi-user.target. This
has made a lot of people very angry and has been widely regarded as a
bad move (or at least, very nonstandard):
15d761a525 (commitcomment-128564097)
This was done because of fragile tests and services declaring
dependencies on multi-user.target when they meant network-online.target.
Let's rip off the bandaid and fix our tests.
This makes it easier to reason about what variables are inserted during packaging.
We also make sure that template file is also valid python syntax, which makes editor errors go away during development.
Removed patches:
- 0007-Fix-hwdb-paths.patch
The directory we want seems to already be included in the list. Is there
a reason why we want to restrict it further?
- 0010-build-don-t-create-statedir-and-don-t-touch-prefixdi.patch
This patch has little to do with how the meson.build file looks now. The
new patch 0017 is the successor to this one.
- 0015-pkg-config-derive-prefix-from-prefix.patch
This is fixed upstream. We don't need this anymore.
The example systemd-sysupdate transfer name has a ".conf" suffix,
although the files on the final system are already appended with this
suffix, so the file ends up being "transfer-name.conf.conf". Remove the
suffix in the example so that users will get a transfer filename they
expect.
Systemd-repart will use loopback devices for partition creation if it is
able to, and will fallback to doing "offline" partition creation writing
data directly to files. From what I see looking at the repart code,
there are specific features that cannot be taken advantage of when not
using loopback devices (e.g. no BTRFS subvolumes in systemd v255) and in
certain places they have to perform some manual re-sizing work that can
otherwise be avoided.
A bootspec could remove the `initrdSecrets` attribute and is a perfectly valid bootspec, as can be seen
in the bootspec.cue.
This makes the builder not fail upon missing `initrdSecrets`.
