Just for the sake of clarity (sorry, I read your previous answer wrong): luarocksitself seems to be installed fine (afaics)
They are the installed “rocks” which are not copied to /usr/lib64
This is what happens if I run a script with require("periphery") if I do not manually copy (or link) “periphery.so” file:
lua: ./release:24: module 'periphery' not found:
no field package.preload['periphery']
no file '/usr/share/lua/5.4/periphery.lua'
no file '/usr/share/lua/5.4/periphery/init.lua'
no file '/usr/lib64/lua/5.4/periphery.lua'
no file '/usr/lib64/lua/5.4/periphery/init.lua'
no file './periphery.lua'
no file './periphery/init.lua'
no file '/usr/lib64/lua/5.4/periphery.so'
no file '/usr/lib64/lua/5.4/loadall.so'
no file './periphery.so'
Maybe I should look into lua-periphery’s installation, but Arch Linux does this fine, that’s why I think it has something to do with luarocks itself.
lib_modules_path (string) - The path where modules with native C extensions will be installed. If you are using a x86_64 *nix OS, you will probably need this line in config.lua: lib_modules_path="/lib64/lua/"..lua_version. See issue 416.
This seems to indicate that luarocks itself has an issue and the built in scripts that install the lua-periphery part need to be updated. Possibly a bug report would be in order?
Up until luarocks 3.9.1, Fedora’s builds were in fact patching its src/luarocks/core/cfg.lua so that it would default to /usr/lib64/ as the library path on 64-bit Fedora installs.
My 3.9.1 update PR includes a note that it “dropped upstreamed patch”, and deletes that patch.
I don’t know what gave me the impression that the patch had been upstreamed, because it clearly hasn’t. (Perhaps it failed to apply to the 3.9.1 sources, and patch offered (as it is wont to do) to try reversing it, leading me to assume that it had already been applied by upstream.)
Regardless, the patch is clearly still necessary. So I’ve restored it from the commit history, and updated it to apply to the 3.9.1 sources. (It did, in fact, not apply cleanly in its original form.) As soon as my mockbuild run finishes and I can test that it fixes the issue, I’ll submit PRs adding the patch back to the luarocks.spec for rawhide, f38, and f37. Hopefully someone can get that committed and produce new builds.
Oh, I very much doubt they will, at least not in its current form as it’s very heavy-handed. All the patch does is check for the existence of a /usr/lib64 directory, and if it finds one it sets that as the default library install path.
That’s fine enough for a local Fedora patch, but for more general use it’s incredibly fragile. Especially since /usr/lib64 is defined as (an optional) part of the Filesystem Hierarchy Standard. Even Ubuntu installs have a /usr/lib64/ directory — their libc6 package installs it — but that should most definitely not be the default install path on Debian-derived systems.
What a more-robust, correct method of determining the default path would look like, so that it could be done by the upstream code, is an open question.
At any rate, I’ve also now submitted PRs targeting the f38 and f37 branches, to make the same fix (and do an update to luarocks 3.9.2) that my previous PR applies to the rawhide branch.
Still, I’m not a maintainer of the luarocks package, and despite there being 16 subscribers besides myself, experience so far tells me that PRs in that repo don’t tend to attract much in the way of response, and certainly not quickly. So I can’t predict how soon this might be fixed.
(I neglected to mention, earlier, that I’ve also filed a bug report about the incorrect default install directory.)