On Wed, Aug 27, 2025 at 04:46:15PM +0200, Pablo Neira Ayuso wrote: > Hi, > > Cc'ing Phil, Jan. > > Excuse me my terse proposal description. > > Extension: This is an alternative patch to disable --with-unitdir by > default, to address distcheck issue. > > I wonder also if this is a more conservative approach, this should > integrate more seamlessly into existing pipelines while allowing > distributors to opt-in to use this. > > But maybe I'm worrying too much and it is just fine to change defaults > for downstream packagers. I think both is fine, packagers will know what to pass to configure and what not. Though I think you should also pass the --with-unitdir=<something> option during distcheck builds, otherwise this patch inadvertently disables the sanity check which sparked just this discussion in the first place. :) As Jan's patch shows, there is AM_DISTCHECK_CONFIGURE_FLAGS for that. Thinking about the original issue, I wonder if the pkg-config method of finding the unit install location is actually problematic: My development build script calls configure with --prefix="$PWD/install" and runs 'make install' as regular user. The only reason why I didn't complain yet is probably because I don't have systemd installed and thus 'pkg-config systemd' fails. So, I'm tempted to ask a fundamental question: Shouldn't --prefix be applied to all installed files? I would say yes, but simply prefixing the pkg-config-returned path by $prefix seems wrong, too as it is definitely not where the unit file is expected to be. Also, --prefix defaults to /usr/local and Fedora for instance passes --prefix=/usr when building SRPMs. OTOH Fedora (Rawhide) returns /usr/lib/systemd/system when requesting systemdsystemunitdir. So maybe prefix $prefix only if it doesn't start with $prefix already? (Seems silly, though.) Cheers, Phil
