[bug#48924] Add systemd

[Leo Prikler]

Am Sonntag, den 13.06.2021, 19:56 +0000 schrieb Tony O:
> Okay, I was going by the similarity to the nix package, but if you
> require concrete proof then I just built it without the sandbox and
> with my kernel supporting cgroups. Exactly 15 test fail, out of
> nearly 400. Each of them by best approximation due to binaries not in
> scope and/or systemd not being PID1 (as is repeatedly echoed on the
> error log).
> 
> If those 15 tests pose a concrete issue to you, I would consider
> fixing them, but only with the guarantee that the result end up in
> guix. As it stands disposition seems to be to not merge this, so I'll
> reserve the effort.
15/400 tests failing sounds somewhat reasonable, especially if we can
explain their failure modes (e.g. stuff like not being PID1).  Even if
we add the other tests, that require cgroups on top, that'd be fine,
but we'd have to be able to display all that info in a meaningful
fashion like
  ;; these tests want systemd to be PID1 
  "foo" "bar" "baz"
  ;; these tests require cgroups
  "spam" "ham" "eggs"
  ;; these are missing libquux
  "i" "ran" "out" "of" "funny" "variable" "names"
However, this is somewhat different from the package description at
hand, which lacks those explanations.

The reference point is of course the thing that's compiled within the
sandbox, not anything without.  Having most tests pass when compiling
stuff "normally" with Guix is perhaps a good indicator, that at least
compiling works, but it's really just that.

Finally – and this might be my ignorance of the systemd test suite
speaking, so ignore me if I say something stupid – just because we have
a test coverage of let's say 90% or even 100%, doesn't mean that the
installed binaries will still be able to work.  There is a large
potential for bugs to sneek in, e.g. through an insufficient wrap
phase, so for software like systemd, we should be able to do some
trivial tasks, e.g. `systemctl start hello-world` with a systemd, that
has not claimed PID1.

TL;DR: the plan is to
- Get the sandboxed package to match up as closely as you can get to
the non-sandboxed one w.r.t. testing.
- Document how the remaining disabled tests fail.
- Prove, that components of systemd run when invoked directly from the
store/from within a suitable environment.

It is probably still a somewhat long and bumpy road, but in my personal
opinion one that has an end.
@lfam, ludo, efraim: WDYT?

Regards,
Leo