A few things we will have to change:

    * systemd now defaults to the "unified" cgroup hierarchy setup during
      build-time, i.e. -Ddefault-hierarchy=unified is now the build-time
      default. Previously, -Ddefault-hierarchy=hybrid was the default. This
      change reflects the fact that cgroupsv2 support has matured
      substantially in both systemd and in the kernel, and is clearly the
      way forward. Downstream production distributions might want to
      continue to use -Ddefault-hierarchy=hybrid (or even =legacy) for
      their builds as unfortunately the popular container managers have not
      caught up with the kernel API changes.

We will have to set this build flag, otherwise things like docker and kubernetes will not work anymore. It is going to take quite a bit more time before docker actually moves to cgroupsv2. Fedora 31 has dropped cgroupsv1 support and has some information about their migration here https://fedoraproject.org/wiki/Changes/CGroupsV2 and here opencontainers/runc#654 (comment)
I think we're better of to support cgroupsv1 for a bit longer as I think dropping docker is a change people will not like. Lets see how this pans out for Fedora Rawhide first ;)

    * Man pages are not built by default anymore (html pages were already
      disabled by default), to make development builds quicker. When
      building systemd for a full installation with documentation, meson
      should be called with -Dman=true and/or -Dhtml=true as appropriate.
      The default was changed based on the assumption that quick one-off or
      repeated development builds are much more common than full optimized
      builds for installation, and people need to pass various other
      options to when doing "proper" builds anyway, so the gain from making
      development builds quicker is bigger than the one time disruption for
      packagers.

I'm not sure if this is an issue, but we should stack generating man pages isn't broken

    * When a [Match] section in .link or .network file is empty (contains
      no match patterns), a warning will be emitted. Please add any "match
      all" pattern instead, e.g. OriginalName=* or Name=* in case all
      interfaces should really be matched.

This will cause issues for us. We currently generate empty [Match] statements when useNetworkd=true. See #18962

systemd-pstore seems to be a new services that we might want to support:

• https://www.phoronix.com/scan.php?page=news_item&px=Systemd-Pstore-Service
• https://www.freedesktop.org/software/systemd/man/systemd-pstore.html

We need to provide both /etc/system/pstore.conf and a matching unit file. As always we can orientate around the upstream examples that will be in $out/share/factory.

I am not sure if it is worth putting the effort for pstore into this PR already or if we just do that afterwards. I still have hopes to include this in 19.09. The deadline is tight but we might be lucky if systemd didn't change that much.

Maybe, but I wouldn't make it a blocker. For example, systemd-portabled doesn't work on NixOS either and that hasn't blocked previous releases

@lheckemann @disassembler (the 19.09 RMs)

What would be required to have this included in 19.09? So far my tests show that this seems to be fairly low impact. I'll work on this during the weekend to see if that holds true.
It would get us down to maintaining one less systemd version during the release cycle (for most of the time anyway).

That would be nice! Since the branch-off is slated for tomorrow, time's pretty short though.

I think I am done here. Rebased onto master and restart my private hydra to test all the NixOS VM tests.

My laptop is running on this PR now and so far it looks fine. Looking for testers with more advanced use cases: @arianvp @fpletz @flokli @Mic92 etc…

@Mic92 addressed your comments. Anything else?

@andir my laptop is still rebuilding... Just from looking at the changes, it seems fine to me.

Update probably when I come later back this evening, it should be ready...

Unless there is some negative feedback I'll merge this into staging within the afternoon (UTC).

If this should still target 19.09, merging into staging probably won't get it into the release-19.09 branch, wouldn't it? Or do we branch-off staging to staging-19.09 as well?

I defer that to the release managers. If it doesn't land anyway they can indicate if they want us to backport into 19.09. I would just get this into unstable now no matter if it reaches 19.09 in the end.

The branch-off hasn't happened yet, I haven't heard from @disassembler but didn't want to go ahead with it without him. I'm not sure if we want to do one more staging merge cycle before the branch-off, but if not I'd be all for porting this onto staging-19.09 since it brings us closer to upstream and will save us divergence work.

Half a day from now the current staging-next cycle (#68244) should be finished building. I suggest merging that and branching-off. We will then have a staging-19.09 again and the systemd change could be cherry-picked in.