Re: systemd units are not installed in 4.19.0-rc2 anymore

[Jan Beulich <jbeulich@xxxxxxxx>]

On 15.07.2024 12:07, Andrew Cooper wrote:
> 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 can see the point here. Still I wonder whether for non-cross builds it
wouldn't make sense for a build env to reflect what the produced code is
intended to run in. Which would mean to make available enough of systemd
to be able to recognize its presence from a configure script.

> 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.

Would 1) have any downsides to Linux systems not coming with systemd? If
not, like Marek says, wouldn't it make sense to put in place respective
stuff unconditionally (by default), even if it may end up unused?

Jan