Alternative/fallback PAM service

[chipb]

There are some rare cases where the user may not have control of the system’s /etc/pam.d directory to install a swaylock service file, but they would still like to be able to use swaylock. For example, a nix user may install swaylock to their user profile without the privileges or knowledge to also update their system’s PAM configuration in order to unlock their screen.

Since I believe these cases involve building swaylock with a different installation prefix already, I’d be inclined to add a meson build option to override the PAM service name. The user can then decide which existing system PAM service matches how they want swaylock to behave and adjust their build accordingly.

As suggested mentioned on IRC by @kennylevinsen, a fallback to the login service if swaylock is not present might be better a possibility. This has may have the benefit of Just Working without another meson option to help with a rare edge case.

(Updated wording to try avoiding misrepresentation. See issue comments immediately below.)

[kennylevinsen]

As suggested on IRC by @kennylevinsen, a fallback to the login service if swaylock is not present might be better.

I strictly speaking did not suggest this, but stated that we have such fallback in greetd (for historical reasons).

[chipb]

I strictly speaking did not suggest this, but stated that we have such fallback in greetd (for historical reasons).

Sorry, I didn’t intend to put words in your mouth. I just wanted to mention that a point was raised of there being possible options aside from the big hammer of direct meson config. No solutions were endorsed, hence the opened issue.