I've uploaded two specfiles: lua4.spec and lua.spec. The first replaces lua.spec from lua-4.0.1-1mdk.src.rpm. The second replaces lua.spec from lua-5.0-1mdk.src.rpm. (I've also uploaded the resulting SRPMs, especially since the 4.0 version doesn't appear to be available on cooker anymore.)
Both have only minor changes, the goal of which is to allow lua4 and lua5 to coexist: lua.spec was renamed to lua4.spec (and the SRPM to lua4), and the executables are now controlled by update-alternatives. Since there are existing packages embedding both versions, and it's not always trivial to update a package to embed the new version, the shared libraries need to be able to coexist. In the current packages, the interpreter and compiler (/usr/bin/lua and /usr/bin/luac, and their man pages) are in the library RPMs, which prevents them from doing so. One solution would be to move the executables into a new package (lua-*.rpm, or into the -devel package (liblua*-devel*.rpm). I haven't tested whether the shared libraries can be embedding if the interpreter executable is missing, but I'd assume they can. Alternatively (NPI), update-alternatives can allow both versions of the interpreter and compiler to coexist. This has the added advantage that a developer who's trying to update her scripts (or her embedding app) from lua4 to lua5 can do so much more easily. This also involves a slightly smaller change to the specfile than the other solution. So, I chose to do it this way. Neither package can coexist with the older packages (4.0.1-1mdk and 5.0-1mdk), so I put in explicit Conflicts tags. A few minor issues: The manpages are not controlled by update-alternatives (the old versions are simply called lua4 and luac4). Although it seems to make sense that "man lua" should call up the lua4 manpage if lua4 is your currently-selected alternative, it looks like other packages don't do this, so I didn't. It might be useful to split the interpreter and compiler off into a separate package from the shared libraries even though update-alternatives makes this unnecessary. On the other hand, I assume that whatever reason Lenny had for including them in the lib package two years ago (when he libpolicy-ified lua-4.0) still makes sense. If you rpm -ivh both SRPMs to ~/RPM, then try to build them both, it may not work (they have a patch file with the same name). I haven't tested that. If you rpm -ivh one, build it, rpm -ivh the other, and build it, that works (in either order); rpm --rebuild on the SRPMs also works fine.
