meson: cracklib dictionary detection isn't working

[rdmark]

This affects both branches, I think.

The with-cracklib compile time option should point to the location of the cracklib dictionary file, IINM. However, the default location isn't valid (on Alpine at least) and passing a path to -Dwith-cracklib=/usr/share/cracklib causes meson to attempt to create a build dir in that location which I don't think is correct.

e.g.

PermissionError: [Errno 13] Permission denied: '/usr/share/cracklib/build'

In the case of Alpine, the default cracklib dictionary is /usr/share/cracklib/pw_dict.pwd

However, after building netatalk with meson, it tries to look for the dictionary at:

alpine:~/netatalk2$ doas afppasswd -a dmark
Enter NEW AFP password: 
/usr/lib64/cracklib_dict.pwd.gz: No such file or directory

[rdmark]

As a side note, I don't think we should build with cracklib support if the build system can't find the cracklib dictionary. Without the dictionary, afppasswd is effectively non-functional when built with cracklib support.

[rdmark]

But then again... we could consider simply removing cracklib support altogether, if doing this in a cross-platform compatible way proves to require too much effort.

It supports a niche of a niche of a niche usecase at this point... The RandNum UAM is really only for providing a modicum of encryption for Apple IIe / IIGS / Mac System Software 6 and early 7 clients. Mac OS 7.5 and later should be using DHX. :)

[ghost]

@rdmark, the cracklib macro is actually borked in both autotools and meson. There are a multitude of cracklib dict locations and the dict has different names on different OSes too. Currently making good progress fixing it...

[ghost]

As a side note, I don't think we should build with cracklib support if the build system can't find the cracklib dictionary. Without the dictionary, afppasswd is effectively non-functional when built with cracklib support.

I agree

[rdmark]

Fixed in main. 2.x needs the fix too.