In order for Gentoo Linux to properly support side-by-side installation of different versions of Lua (including LuaJIT), please migrate this package as to lua.eclass (for packages which should support multiple Lua implementations at the same time, i.e. most likely Lua modules) or lua-single.eclass (for packages which only have to support one Lua implementation at a time). For details, consult documentation of respective eclasses as well as already-migrated ebuilds in the tree. Please note that since slotted dev-lang/lua is currently masked, your migrated ebuilds should be masked as well. There is a section of package.mask, created in September 2020, which you can use for this purpose so that it will be easier in the future to unmask them all in one go. Thank you in advance for your effort!
I temporary masked lua use flag
While the masking of USE=lua in exact-image simply means that this package will not prevent the unmasking of slotted Lua (thanks!), this isn't actually fixed yet. Since we haven't got the resolution state "LATER", I'm switching it to so that this ticket can clearly be distinguished from ones which have been closed following successful migration.
PS. Regarding your comment in package.mask, slotted dev-lua IS already available in the tree - all one has to do is unmask it (as well as app-eselect/eselect-lua).
Created attachment 670193 [details] exact-image-1.0.2.ebuild migrated to lua.eclass I had some free time so I have had a look at exact-image source code to see how it handles the building of Lua bindings. Attaching an ebuild which IMHO will do the job. Note that it doesn't actually work yet, some changes will be necessary in order for api/lua/Makefile to receive all the necessary variables - that however is no longer an ebuild matter. By the way, you should add REQUIRED_USE="lua? ( swig )" even to pre-migration ebuilds - as things stay now, if you build exact-image with USE="-swig lua" emerge will quietly NOT install Lua bindings.
One more thing, when you modify the upstream makefile make sure you put object files and the linked Lua module into implementation-specific directories so that ones for different implementations do not clobber one another. Or you could use lua_copy_sources, except you'll have to think when to do it so that you do not unnecessarily recompile things which have got nothing to do with Lua bindings.
The problem with this ebuild is that I do not know how to test the LUA binding. I have used the binary and as it was going to the trash, I accepted to take it. If you know how to maintain the lua binding for that, pleas do it
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=75282e006c40ea6ce4dc3c784c5c7a3e23285960 commit 75282e006c40ea6ce4dc3c784c5c7a3e23285960 Author: Conrad Kostecki <conikost@gentoo.org> AuthorDate: 2021-03-26 00:17:16 +0000 Commit: Conrad Kostecki <conikost@gentoo.org> CommitDate: 2021-03-26 00:21:20 +0000 media-gfx/exact-image: add support for slotted lua Closes: https://bugs.gentoo.org/752741 Package-Manager: Portage-3.0.16, Repoman-3.0.2 Signed-off-by: Conrad Kostecki <conikost@gentoo.org> media-gfx/exact-image/exact-image-1.0.2-r1.ebuild | 105 ++++++++++++++++++++++ 1 file changed, 105 insertions(+)
