30.06.2016, 10:26, "Anton D. Kachalov" <[email protected]>: > Hello, Jo. > > 30.06.2016, 01:15, "Jo-Philipp Wich" <[email protected]>: >> Hi Anton, >> [...] >> Overwriting existing packages with other packages having the same name >> from external feeds is messy and will always lead to undefined behavior, >> don't do that. What would probably work is packaging luajit separately >> and replace the existing /usr/bin/lua with a program like: >> >> -- 8< -- >> #!/bin/sh >> >> if [ -x "/usr/bin/luajit" ]; then >> exec /usr/bin/luajit "$@" >> else >> exec /usr/bin/lua.bin "$@" >> fi >> -- >8 -- > > This variant do not solve packages' dependencies problem. And I still need to > somehow recompile (and disable mainstream "lua" first) packages with LuaJIT > libs. Brute replacement works better in such case. I don't want to waste > space for two Lua version in the system. > Just a generic question – what is the obstacles to move from Lua interpreter > to LuaJIT? There are minor changes in regexp's quotes. Other things seems to > work. I've completely recompile stuff with LuaJIT.
Just look at the source of LuaJIT. It has limited arches support (x86, mips, arm, ppc). Might it be better to rename "lua" to "lua-interpeter" or so and make it provides "lua" and "liblua". Then do the same for "luajit". Thus we make can choose "luajit" when it available and not to break everything in terms of dependencies. From other packages' view, such virtual dependencies to "lua" and "liblua" might point either to lua-interpeter or luajit packages. -- Anton D. Kachalov _______________________________________________ openwrt-devel mailing list [email protected] https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
