[opensuse-factory] lua v5.2 & v5.1 coexistence -- separate -devel/headers should be allowed
Default lua install on 12.3/Factory is v5.2, rpm -qa | grep -i lua | sort liblua5_2-5.2.1-2.2.1.x86_64 lua-5.2.1-62.1.x86_64 lua-devel-5.2.1-2.2.1.x86_64 lua-doc-5.2.1-2.2.1.noarch It is installed with alternatives support, update-alternatives --list lua /usr/bin/lua5.2 Attempt to co-install lua51 requires *deinstall* of lua 52 devel, zypper in lua51 lua51-devel lua51-doc Loading repository data... Reading installed packages... Resolving package dependencies... Problem: lua51-devel-5.1.5-2.1.3.x86_64 conflicts with lua-devel provided by lua-devel-5.2.1-2.2.1.x86_64 Solution 1: deinstallation of lua-devel-5.2.1-2.2.1.x86_64 Solution 2: do not install lua51-devel-5.1.5-2.1.3.x86_64 Choose from above solutions by number or cancel [1/2/c] (c): Lua v51 & v52 headers represent different lua API. E.g., luajit build (from upstream) requires 5.1 API. The lua v51 & v52 app & devel packages should install in separate namespaces, and be selectable with update-alternatives. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 26.03.2013 16:43, schrieb darx@sent.com:
It is installed with alternatives support,
update-alternatives --list lua /usr/bin/lua5.2
Attempt to co-install lua51 requires *deinstall* of lua 52 devel,
Wrong.
zypper in lua51 lua51-devel lua51-doc Loading repository data... Reading installed packages... Resolving package dependencies...
Problem: lua51-devel-5.1.5-2.1.3.x86_64 conflicts with lua-devel provided by lua-devel-5.2.1-2.2.1.x86_64 Solution 1: deinstallation of lua-devel-5.2.1-2.2.1.x86_64 Solution 2: do not install lua51-devel-5.1.5-2.1.3.x86_64
"Attempt to install lua51-devel requires deinstall of lua52-devel" IMVHO this is sensible. Or why would you need both devel packages at once installed (you can only use one at a time anyway without very ugly hacks)? Instead of update-alternatives mess, you can also just switch to the package you need. -- Stefan Seyfried "If your lighter runs out of fluid or flint and stops making fire, and you can't be bothered to figure out about lighter fluid or flint, that is not Zippo's fault." -- bkw -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, Mar 26, 2013, at 08:58 AM, Stefan Seyfried wrote:
Or why would you need both devel packages at once installed
Building two daemons on the same box, one using lua 5.2 API, the other using luajit+lua5.1 API. Happens all the time. I currently solve it by NOT depending on opensuse's pkgs, an building/installing lua 5.1 from upstream source.
(you can only use one at a time anyway without very ugly hacks)?
Wrong. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 26.03.2013 17:23, schrieb darx@sent.com:
On Tue, Mar 26, 2013, at 08:58 AM, Stefan Seyfried wrote:
(you can only use one at a time anyway without very ugly hacks)?
Wrong.
And how do you select wich liblua.so is used for linking (without ugly hacks?) -- Stefan Seyfried "If your lighter runs out of fluid or flint and stops making fire, and you can't be bothered to figure out about lighter fluid or flint, that is not Zippo's fault." -- bkw -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, Mar 26, 2013, at 01:50 PM, Stefan Seyfried wrote:
Wrong.
And how do you select wich liblua.so is used for linking (without ugly hacks?)
add "-Wl,-rpath,$(path to whichever liblua.so)" to LDFLAGS or equivalent read: man ld -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 26.03.2013 22:01, schrieb darx@sent.com:
On Tue, Mar 26, 2013, at 01:50 PM, Stefan Seyfried wrote:
Wrong.
And how do you select wich liblua.so is used for linking (without ugly hacks?)
add "-Wl,-rpath,$(path to whichever liblua.so)" to LDFLAGS or equivalent
That's what I meant with "ugly hacks" ;-) I personally think the current solution is fine: different liblua* packages are installable in parallel but only one lua-devel. I'd rather not go through update-alternatives to switch all include-files and the library symlinks. -- Stefan Seyfried "If your lighter runs out of fluid or flint and stops making fire, and you can't be bothered to figure out about lighter fluid or flint, that is not Zippo's fault." -- bkw -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, Mar 27, 2013, at 06:25 AM, Stefan Seyfried wrote:
That's what I meant with "ugly hacks" ;-)
Whatever ... It's well-documented, standard usage, and the correct manner in which to link to a specific library.
I personally think the current solution is fine: different liblua* packages are installable in parallel but only one lua-devel. I'd rather not go through update-alternatives to switch all include-files and the library symlinks.
Since you can't actually install both API versions' devel-headers as concurrent packages, It won't be an issue for you and you won't have to be phobic of standard build methods ... -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wednesday 2013-03-27 14:25, Stefan Seyfried wrote:
Am 26.03.2013 22:01, schrieb darx@sent.com:
On Tue, Mar 26, 2013, at 01:50 PM, Stefan Seyfried wrote:
Wrong.
And how do you select wich liblua.so is used for linking (without ugly hacks?)
add "-Wl,-rpath,$(path to whichever liblua.so)" to LDFLAGS or equivalent
That's what I meant with "ugly hacks" ;-)
I personally think the current solution is fine: different liblua* packages are installable in parallel but only one lua-devel. I'd rather not go through update-alternatives to switch all include-files and the library symlinks.
The simple solution would be for upstream to provide a library with SONAME liblua-5.1.so instead of liblua.so.5.1, then this would all be a no-brainer because you could start using -llua-5.1. (And a liblua.so symlink can be switched according to taste.) It's that simple. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
The simple solution would be for upstream to provide a library with SONAME liblua-5.1.so instead of liblua.so.5.1, then this would all be a no-brainer because you could start using -llua-5.1. (And a liblua.so symlink can be switched according to taste.) It's that simple.
1st, I'm talking about the devel-headers, not the lib. the libs already can coexist: zypper in liblua5_1 ... Resolving package dependencies... Problem: conflicting requests Solution 1: do not forbid installation of liblua5_1-5.1.5-2.1.3.x86_64[OS12-oss] Solution 2: do not ask to install a solvable providing liblua5_1.x86_64 = 5.1.5-2.1.3 Choose from above solutions by number or cancel [1/2/c] (c): 1 Resolving dependencies... Resolving package dependencies... The following NEW package is going to be installed: liblua5_1 1 new package to install. Overall download size: 77.2 KiB. After the operation, additional 192.6 KiB will be used. Continue? [y/n/?] (y): y Retrieving package liblua5_1-5.1.5-2.1.3.x86_64 ... rpm -qa | grep -i liblua liblua5_2-5.2.1-2.2.1.x86_64 liblua5_1-5.1.5-2.1.3.x86_64 ls -al /usr/lib64/liblua* -rw-r--r-- 1 root root 1.7M Feb 5 06:41 /usr/lib64/liblua.a lrwxrwxrwx 1 root root 13 Mar 15 08:11 /usr/lib64/liblua.so -> liblua.so.5.2 -rw-r--r-- 1 root root 193K Jan 26 15:32 /usr/lib64/liblua.so.5.1 -rw-r--r-- 1 root root 217K Feb 5 06:41 /usr/lib64/liblua.so.5.2 tho I agree that -llua-5.1 would be convenient. lib naming is also trivial to implement in obs @distro, or via simple build locally. Getting cooperation from upstream is a challenge; lua's suffering from upstream politics. 5.1-usage is being kept alive by the luajit (widely used for performance enhancement in, e.g., nginx/apache/etc) devs -- who, so far, for long-winded reasons, refuse to use 5.2 and its API -- whereas the just-lua folks argue that 5.1 is deprecated and 5.2 should be used. Also, luasocket STABLE is NOT currently 5.2-API compatible (@ git is, https://github.com/diegonehab/luasocket/tree/unstable). The upstream 5.1 vs 5.2 politics are not something I can solve. namespace-separated headers is already done in-distro. e.g. /usr/include/gtk-{2.0,3.0}, /usr/include/python-{2.7,3.0}, etc. why is /usr/include/lua-{5.1,5.2} such a problem? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 27.03.2013 16:00, schrieb darx@sent.com:
The upstream 5.1 vs 5.2 politics are not something I can solve.
namespace-separated headers is already done in-distro. e.g. /usr/include/gtk-{2.0,3.0}, /usr/include/python-{2.7,3.0}, etc.
This is done by gtk-upstream.
why is /usr/include/lua-{5.1,5.2} such a problem?
you would need to patch every single program you would want to compile (or add custom CFLAGS and stuff). If you know how to do that, it will be very easy to just put the liblua.so symlink in ~/lua51/lib and the lua51 includes in ~/lua51/include. /usr/include/lua-5.[12345] would be a SUSE-specific solution AFAICT and I'd hate to introduce stuff like that without very good reasons. Best regards, seife -- Stefan Seyfried "If your lighter runs out of fluid or flint and stops making fire, and you can't be bothered to figure out about lighter fluid or flint, that is not Zippo's fault." -- bkw -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
do what you want. i frankly don't care ... there are better distro options for development than fighting with the least-common-denominator here. good luck with your fear of 'ugly-hacks'. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Quoting Stefan Seyfried
Am 27.03.2013 16:00, schrieb darx@sent.com:
The upstream 5.1 vs 5.2 politics are not something I can solve.
namespace-separated headers is already done in-distro. e.g. /usr/include/gtk-{2.0,3.0}, /usr/include/python-{2.7,3.0}, etc.
This is done by gtk-upstream.
why is /usr/include/lua-{5.1,5.2} such a problem?
you would need to patch every single program you would want to compile (or add custom CFLAGS and stuff).
that's the job of pkg-config and as such the provided .pc file.. BUT: as upstream has only one namespace (lua), anybody will be using pkg-config --cflags lua to find the right location of the headers... we can not change the name of the .pc file without breaking everything. so, yes.. moving the /usr/include stuff out into /usr/include/lua-5.[12] is possible, but does not solve everything... just check what lua(-51)?-devel provides on file level: /usr/include/lauxlib.h /usr/include/lua.h /usr/include/lua.hpp /usr/include/luaconf.h /usr/include/lualib.h /usr/lib64/liblua.a /usr/lib64/liblua.so /usr/lib64/pkgconfig/lua.pc => /usr/include => solvable => /usr/lib64/liblua.a (eeks.. that should live in a -devel-static anyway!) => /usr/lib64/liblua.so => tough.. => /usr/lib64/pkgconfig/lua.pc => no way to change the name without breaking everything. so before looking at the whole picture, solving the small issue being the location of the headers is 100% waste of time. Dominique -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (4)
-
darx＠sent.com -
Dominique Leuenberger a.k.a. Dimstar -
Jan Engelhardt -
Stefan Seyfried