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

Reply via email to