netatalk2 uses wrong path for systemd unit files

[VorpalBlade]

I'm trying to create a package for ArchLinux AUR of the 2.2 version of netatalk (to be able to use with my retro computers). I noticed that make install puts the systemd units in the wrong location: /lib/systemd as opposed to /usr/lib/systemd.

I made sure to pass --prefix=/usr and --enable-systemd to configure, so I don't know why this is happening. I also don't see any separate prefix variable for systemd unit files in configure --help.

Looking at distrib/initscripts/Makefile.in it does in fact seem like servicedir is hard coded to /lib/systemd/system which is wrong on distros that have done the /usr-merge. On Arch /lib is a symlink to /usr/lib. Presumably a configure option needs to be added for this.

[rdmark]

Thanks for reporting! The hard coding is my fault. I agree that we need a more portable solution. Perhaps we can try porting the --with-init-style logic of netatalk3. Although even better would be if the OS/distro could be autodetected by autoconf.

netatalk/macros/netatalk.m4

Line 495 in 7dbde0c

dnl Check for optional initscript install

If you have a better idea, or want to take a stab at porting, please don't hesitate to raise a PR.

[VorpalBlade]

Thanks for the quick response. I figured out a workaround for now:

make DESTDIR="$pkgdir/" servicedir=/usr/lib/systemd/system install

I'll freely admit is a hack, but it will work for now.

I'm not sure that it would make sense to auto detect OS/distro: There are so many of them, are you going to have an up-to-date list of all of them and what their policies for systemd files are? If you could auto detect where systemd files go, that would be fine (e.g. if something like pkg-config could tell you). I just think it would be madness to detect distro and have a table based on that.

[VorpalBlade]

Looking at the code you linked, it looks to me like there is no difference between suse-systemd, redhat-systemd and systemd. Only debian-systemd (and the non-systemd) are different? Which raises the question why you need multiple options for it. It seems to me it would make more sense to simply have systemd-usr and systemd-root or something like that.

[rdmark]

Fair point. The KISS principle should be kept in mind. No need to over-engineer a solution for a simple problem.

By virtue of not changing the current behavior, how about:

• Keep --enable-systemd as is (the Debian scenario)
• Add a --enable-systemd-usr option (everyone else)

[VorpalBlade]

Sounds good to me

[rdmark]

Here's another approach that would be a bit more sophisticated:

Have a single --enable-systemd and make it configurable with a new --systemddir=PATH option.

Or perhaps even simpler, --enable-systemd that takes an optional PATH to systemddir. I think autoconf syntax supports this.

I did an empirical investigation with Debian 11, 12 and Ubuntu 22.04. All three are actually symlinking /lib to /usr/lib so I don't think we even need to keep the traditional Debian case, and let the default be /usr/lib/systemd for all platforms.

So, how about doing a check for existence of the /usr/lib/systemd dir and if True enable systemd by default (can be overridden by other init type options specified manually)?

[VorpalBlade]

I believe debian is still in the process of transitioning to merged /usr? New installs default to merged users, but old installs that you keep updating to not. I remember reading an article this year about it on lwn.net. Seemed to be a bit of a mess.

[rdmark]

Can you test if this solution works for you on Arch? #417

[rdmark]

For the record, I changed my mind about the aggressive auto-detection of systemd and removed it. Having to opt out of systemd is probably counterintuitive for a lot of users, plus it introduced issues with distcheck.

[VorpalBlade]

Can you test if this solution works for you on Arch? #417

Seems to work yes.

[rdmark]

Cheers, I've merged the PR now.