Re: [gentoo-dev] Slotted Lua + revdeps to be unmasked on Christmas Eve

[Michael Orlitzky]

On 12/23/20 8:35 AM, Jaco Kroon wrote:
> Michael,
>
> I'm busy disecting what Marek has done for asterisk as I need to make
> that work for multiple versions of net-misc/asterisk-16.14.0-r100, not
> merely the one he did it for - perhaps that would be helpful for you as
> well?
>
> I don't know lua at all.
>
> Anyway, I'm on IRC as jkroon if you'd like to exchange notes.  I don't
> particularly like the patch Marek did as I'll NEVER be able to push that
> upstream.  The patch will work for us, but as a policy I highly prefer
> patches which I can get unstreamed such that we don't need to carry them
> more than one or two versions.

Agreed. This is more of a system library packaging issue than anything 
to do with Lua specifically.


> I'd prefer to patch upstream to keep it's behaviour of detecting a lua
> version, but have a --with-lua(version)? type argument that can take an
> optional argument which will then be the version, but --with-* generally
> takes a prefix where the include and lib folders can be found ... and
> I'd prefer to depend on pkg-config as primary and fallback to the
> ./configure mess which tries to guess at things ...
>

This is exactly what I'm trying to get across. Support for multiple 
versions of libraries in weird locations is not a new thing. Generally, 
you can put CPPFLAGS="-I/foo/bar" and LIBS="-L/baz/quux" before running 
./configure and everything will just work with your header files and 
libraries in the non-standard paths /foo/bar and /baz/quux, 
respectively. Those paths take precedence over the defaults (if used 
correctly...), so you can use them to override the default version of a 
library and compile/link against a specific copy if you need to do that. 
Likewise, one could prepend a path to PKG_CONFIG_PATH to override the 
version that will be detected via pkg-config.

The problem that we've gotten ourselves into is that we've copied Debian 
by not only relocating the library, but renaming it (and its *.pc file) 
entirely. There is no good way to tell an autotools build system that 
you've renamed a library completely, and that it should prefer the 
renamed version over the standard one if the standard one also exists.

If you want to build against the eselected version of Lua on Gentoo, 
then eselect-lua makes everything OK. It creates symlinks from the 
standard names to the nonstandard ones, and everything just works. But 
if you want to build against a specific, not-eselected version of Lua? 
You have to tell the build system what to do. The eselected version 
lives in the correct locations (via those symlinks), so the build system 
is going to want to find that first. If the eselected version is not the 
one you want to build against,.... oops. Then, since the version you 
*do* want to link against has the wrong name, you have to tell the build 
system to link against it somehow. You can't simply override the 
PKG_CONFIG_PATH, because our *.pc files have the wrong names. You can't 
just override the library search path, because our libraries have the 
wrong names.

The work I've done so far for OpenDKIM does nothing to address these 
larger problems. If lua.pc is on the system, it will get used first, 
regardless of the version you actually want to build against. AFAIK 
there's no good way around this without patching.

If the libraries (and pkg-config files?) were installed to 
subdirectories instead, then the standard method of overrides could be 
used to build against a specific version, rather than requiring every 
upstream build system to support our weird layout.