> DO NOT use pseudo-releases or tarballs created by third parties. In particular, automatic tarballs made by GitHub and other mirrors are lacking the .git directory and will not properly build anymore.
It's a little concerning that their build process relies on a .git directory being present. That's going to make it quite tough for packagers to actually package this.
If the attribute export-subst is set for a file then Git will expand several placeholders when adding this file to an archive. The expansion depends on the availability of a commit ID, i.e., if git-archive[1] has been given a tree instead of a commit or a tag then no replacement will be done. The placeholders are the same as those for the option --pretty=format: of git-log[1], except that they need to be wrapped like this: $Format:PLACEHOLDERS$ in the file. E.g. the string $Format:%H$ will be replaced by the commit hash. However, only one %(describe) placeholder is expanded per archive to avoid denial-of-service attacks.
I'm confused what you mean. What is a packager doing here? I always assumed that the intention of this library is that you, as a developer, compile and embed it in a product that needs a scripting engine. What use would a standalone LuaJIT package be?
Even ignoring the installed interpreter, libraries on Linux distributions are usually installed system-wide as their own packages which other packages depend on (neovim, mpv, cgit, etc.)
if you apt install libluajit-5.1-dev you can compile and link your c programs with it without having to compile it yourself
similarly if you are writing programs in lua rather than in c you can run them in luajit if you just apt install luajit
if you want to release your programs as free software so other people can compile and link them, it's important for them to be able to get the version of luajit you were using so they can debug why your program doesn't work in the current version of luajit
> Surely a packager would be working off of the actual releases not a random git archive?
There are no official releases. To quote from the linked email:
> No release tarballs or binaries are made available. Please do not use obsolete versions from older tarballs or zip files. Please remove any outdated links to these downloads -- they will cease to work soon.
The only way to get a release version of LuaJIT is to compile it from the git repo.
The packagers can make their own snapshot, but they don't want to grab a full .git directory for the source - distributions such as Debian never want to do that: The packager is responsible for auditing all the code including copyright status in the artifacts - best not have the whole history of the project included in that case, because the task is then a little bit too big.
You can clone a specific tag or branch from a git repository without the full history. It looks like LuaJIT's git repository does not support this, although the github mirror does:
It's a little concerning that their build process relies on a .git directory being present. That's going to make it quite tough for packagers to actually package this.