It seems there are unrelated changes to nunc stans stress test and lib389 init.py. Are these really required here?

They are not required here :) I'll fix this up

@vashirov Would you mind checking this again?

It's not working as expected. After building rpm, defaults.inf contains non-replaced value:

tmpfiles_d = @tmpfiles_d@

You also need to update Makefile.am where this replacement happens. Or revert back this chunk:

- tmpfiles_d = @with_tmpfiles_d@
+ tmpfiles_d = @tmpfiles_d@

I don't have a systemd capable machine to test with, but I can confirm the value looks like it's getting through now. I think the issue is the lack of the AC_SUBST outside of the systemd check which needed to be present to set empty/value when defined. I've also fixed the naming.

@vashirov Can you check this please :)

You have spaces around =
Because of that during the build I see the following error:

checking for --with-tmpfiles-d... ./configure: line 22831: tmpfiles_d: command not found                                                                                     

And as a consequence, tmpfiles_d is set to empty value in defaults.inf.

Removed spaces :)

Thanks, ack!

I forgot that perl utils also use with_tmpfiles_d:

# setup-ds.pl 
Global symbol "@with_tmpfiles_d" requires explicit package name (did you forget to declare "my @with_tmpfiles_d"?) at /usr/lib64/dirsrv/perl/DSCreate.pm line 1069.
Global symbol "@with_tmpfiles_d" requires explicit package name (did you forget to declare "my @with_tmpfiles_d"?) at /usr/lib64/dirsrv/perl/DSCreate.pm line 1433.
Compilation failed in require at /usr/sbin/setup-ds.pl line 21.
BEGIN failed--compilation aborted at /usr/sbin/setup-ds.pl line 21.

This broke dscreate:

[mareynol@localhost cli]$ sudo ./dscreate from-file /data/dssetup.inf

Starting installation...
Created symlink /etc/systemd/system/multi-user.target.wants/dirsrv@localhost.service → /usr/lib/systemd/system/dirsrv@.service.
Error: [Errno 2] No such file or directory: '@tmpfiles_d@/dirsrv-localhost.conf'

:( Did you want me to fix this up as well? This is in 1.4.x? I know we support pl tools for 1.3.x, but if this is 1.4.x, is there a reason we still check them?

Yes, please. 1.4 still ships with legacy tools in Fedora and RHEL8. We need to provide an upgrade path for existing users. That means they should work as before, although should not be used interchangeably.

I'll do this as a priority now then (I think it's blocking @mreynolds in another patch).

https://pagure.io/389-ds-base/pull-request/50174

389-ds-base is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in 389-ds-base's github repository.

This pull request has been cloned to Github as issue and is available here:
- https://github.com/389ds/389-ds-base/issues/3184

If you want to continue to work on the PR, please navigate to the github issue,
download the patch from the attachments and file a new pull request.

Thank you for understanding. We apologize for all inconvenience.