lua-filesystem has not been properly updated since 2015; we missed the
1.7.0 release in 2017 and the 1.8.0 release in April last year.
The changelogs seem to indicate this should be backward-compatible, but
if your package depends on the `lfs` module please test:
This package is already in RHEL so there's no EPEL updates, but the
updated spec has been tested on EPEL8 as well.
❯ sudo dnf repoquery --whatrequires lua-filesystem
I've kept the stable autokarma to +3 and disabled the auto-promoting by
time to make sure this does not get accidentally promoted.
Thanks to Robert Scheck for helping modernize the spec (and is now co-
maintaining the package). I've further cleaned it up to match what will
be in the upcoming Lua packaging guidelines.
Michel Alexandre Salim
Some exciting updates re: Lua packaging
TL;DR we want to simplify the Lua packaging experience as much as
possible, across both Fedora and RHEL.
- before RHEL 7, the Lua RPM does not provide "lua(abi) = MAJ.MIN" so a
package that ships Lua modules has to declare this to be safe:
Requires: lua >= MAJ.MIN
Requires: lua < MAJ.(MIN+1)
- we have a draft packaging spec that recommends defining luapkgdir
(noarch) and lualibdir (arched); this was later pre-defined as
lua_pkgdir and lua_libdir in lua-devel in Fedora and RHEL8 -- but
didn't get merged into lua in RHEL < 8.
- there's a %lua_requires macro that automatically generates the right
Requires line. But if it is not present on the system where the SRPM is
regenerated it cannot be used. And lua-devel is not pulled in by
redhat-rpm-config so that means this macro was never used.
- on Fedora >= 33 (and so RHEL >= 9 when it's out) a requires generator
will automatically generate the 'Requires: lua(abi)' line.
- third-party Lua modules are mostly not updated to use these macros,
and worse, EL RPMs can't
On Fri, 2020-08-28 at 19:43 -0700, Michel Alexandre Salim wrote:
> I've created a review request for the proposed new macro package
> If this is accepted:
> - we can immediately branch and ship this for EL6 and EL7 so Lua
> packages for those releases can use macros
> - I'll get redhat-rpm-config to pull in lua-srpm-macros, the same way
> it pulls in other *-srpm-macros packages
> - I'll refactor lua in Fedora so lua-devel pulls in lua-rpm-macros
> rather than shipping macros.lua, then enable shipping macros.lua in
> lua-rpm-macros (right now it's excluded on Fedora to avoid file
lua-rpm-macros is now live in Rawhide, and lua-5.4.0-7.fc34 requires
that package if rpm-build is installed.
spot is pushing a security update for Lua in F33, so the change is not
out yet on that release (I've merged in the changes from master though,
so lua-rpm-macros + lua-5.4.0-8.fc33 will have them).
I've also built lua-rpm-macros for EL6, EPEL7 and EPEL8 (on EPEL8 it
only generates lua-srpm-macros since macros.lua is already shipped by
lua-devel, and we can't refactor that easily as it's part of RHEL
Next step is to have redhat-rpm-config depend on lua-srpm-macros
(needed especially so that on Fedora < 33 and RHEL, we can use the
%lua_requires macro to automatically generate the right runtime
Requires: on the right Lua version).
One thing I'm not sure about is how to get redhat-rpm-config fixed for
stable releases (F31, F32). redhat-rpm-config normally gets updated by
bumping the version, but presumably cherry-picking this one change is
better than shipping the latest redhat-rpm-config on stable releases?
Also -- any idea how to get lua-srpm-macros available in the Koji
builders for EL6, EPEL7 and EPEL8? Presumably we can't touch redhat-
> I'll also look at creating an official SIG including having a mailing
The mailing list has been created (cc: ed on this post). I'd welcome
anyone interested in Lua packaging, especially those who maintains core
Lua packages, to subscribe to lua(a)lists.fedoraproject.org.
Michel Alexandre Salim
chat via email: https://delta.chat/
GPG key: 5DCE 2E7E 9C3B 1CFF D335 C1D7 8B22 9D2F 7CCC 04F2