The merge request for this feature is here: https://github.com/systemd/systemd/commit/4119d1e60a111bacca359b61b5bc3dae29932b67 https://github.com/systemd/system

The merge request for this feature is here: https://github.com/systemd/systemd/commit/4119d1e60a111bacca359b61b5bc3dae29932b67 https://github.com/systemd/systemd/commit/4119d1e60a111bacca... -- more than 21K new lines of code. I'm not too worried about this being a "predictable interface names" type of solution to a problem I'm not having. What I'm really worried about is that of those 21K lines of code, only about 100 lines deal with testing, in the form of two bash scripts performing end-to-end tests against the main executable `homectl`. At $DAYJOB, we find that to achieve any sort of acceptable coverage (which we've arbitrarily defined as 80% or better) -- you'd expect the ratio of production code to unit test code to be close to 1:1, and not anywhere near the 200:1 like this code here. I mean, either those are some _very_ efficient E2E tests, or we have a small number of happy paths being covered here, and we the users will have to weed out all the corner cases that weren't tested. Moreover, since these are E2E tests and not unit tests, that makes me immediately worry about the quality of the code. I know that unit testing is not very common on C-land, but is it really that unheard of in C-land in 2020?