On 15/07/2024 9:11 am, Jan Beulich wrote: > On 13.07.2024 15:02, Andrew Cooper wrote: >> On 13/07/2024 3:45 am, Marek Marczykowski-Górecki wrote: >>> Hi, >>> >>> Something has changed between -rc1 and -rc2 that systemd units are not >>> installed anymore by default. >>> >>> Reproducer: >>> >>> ./configure --prefix=/usr >>> make dist-tools >>> ls dist/install/usr/lib/systemd/system >>> >>> It does work, if I pass --enable-systemd to ./configure. >>> >>> My guess is the actual change is earlier, specifically 6ef4fa1e7fe7 >>> "tools: (Actually) drop libsystemd as a dependency", but configure was >>> regenerated only later. But TBH, I don't fully understand interaction >>> between those m4 macros... >> Between -rc1 and -rc2 was 7cc95f41669d >> >> That regenerated the existing configure scripts with Autoconf 2.71, vs >> 2.69 previously. >> >> Glancing through again, I can't spot anything that looks relevant. >> >> >> 6ef4fa1e7fe7 for systemd itself was regenerated, and I had to go out of >> my way to get autoconf 2.69 to do it. > Yet was it correct for that commit to wholesale drop > AX_CHECK_SYSTEMD_ENABLE_AVAILABLE? That's, afaics, the only place where > $systemd would have been set to y in the absence of --enable-systemd.
Hmm. Yes it was right to drop that, because the whole purpose of the change was to break the dependency with systemd. Thereafter, looking for systemd in the build environment is a bogus heuristic, and certainly one which would go wrong in XenServer's build system where the Mock chroot strictly has only the declared dependencies. I see two options. 1) Activate Systemd by default on Linux now (as it's basically free), or 2) Update CHANGELOG to note this behaviour Personally I think 2 is the better option, because we don't special case the other init systems. ~Andrew