Address some nits that would be helpful for platform builders

[kevans91]

My main concern here is FreeBSD, though I suspect other platforms would also benefit. We're currently on an old version based out of the original repo, but I'd quite like to update it- a few env vars that we can set to point at the correct names for the expected programs would be incredibly helpful.

[alerque]

The content here looks fine. In the nits department though I'd like the commit messages to follow the conventional commits scheme we've been using. Both these commits should be chore: commits with a capitalized imperative mode verb beginning the message after that, as in chore: Add some ....

Also it isn't very important, buy your commit messages implies the binary name thing is only a platform issue, but it isn't. Some Linux distros actually have exactly the same issue.

[alerque]

And don't worry about the failed CI job, that's a known issue with the job itself right now.

[kevans91]

The content here looks fine. In the nits department though I'd like the commit messages to follow the conventional commits scheme we've been using. Both these commits should be chore: commits with a capitalized imperative mode verb beginning the message after that, as in chore: Add some ....

Fixed, thanks!

Also it isn't very important, buy your commit messages implies the binary name thing is only a platform issue, but it isn't. Some Linux distros actually have exactly the same issue.

Right, so I mainly didn't want to speak overly broadly here- I haven't looked at anything but FreeBSD personally, though I could see where others probably have the same issues.

The other problem I have is with luarocks unpack in general. I haven't gone spelunking through other systems packaging yet to decide if we're just behind the trend yet, but I don't think we do any packaging of system rocks today (and this may be something we want to fix). We don't allow any sort of network access during the build (which I think is probably not-uncommon), so these kinds of dependencies have to be satisfied locally in some fashion. (edit for clarity: there's of course a fetch phase right before if we really have to re-organize things to do that independently, but it'd be preferred to handle as part of building, e.g., the luafilesystem port).

[alerque]

The other problem I have is with luarocks unpack in general. I haven't gone spelunking through other systems packaging yet to decide if we're just behind the trend yet, but I don't think we do any packaging of system rocks today (and this may be something we want to fix). We don't allow any sort of network access during the build (which I think is probably not-uncommon), so these kinds of dependencies have to be satisfied locally in some fashion.

I wouldn't use luarocks unpack at all for distro packaging, I would use luarocks make paired with luarocks install instead. See for example how we package this for Arch Linux. The build() phase technically does have network access but we strongly discourage it.

Note how this is taking the locally extracted sources and guided by the local copy of the rockspec is making a LuaRocks rock out of them. Then we install that, also locally and NOT including any dependencies we install those to a predefined tree that will eventually be copied into the target system. Because dependencies are excluded, no network access is needed and the system package manager is expected to supply the right dependencies.

The bit about manifests is taken care of in Arch Linux by a hook that runs after the package manager installs anything to the luarocks directory. This way the system always has an updated manifest with all the system-installed luarocks without LuaRocks messing with it directly as part of each package installation.