Bugzilla Bug 155518

Due to API breakage in lua-5.1.1 i dropped your keywords. Please test and readd
as you see appropiate. Please note that upstreams build system changed quite a
bit and i introduced a modified debian patch to fix it. Please keep an extra
eye open for possible bugs.

Although I have seen that they have a really ill build system I give away ~x86
today.

added ~ppc64

All I can say is that it seemingly compiles well and that it complained about a
couple of sample scripts that I tried. Marked ~hppa.

tolua, ion3 and lighttpd cannot build against lua-5.1.1 because they cannot
find -llua

Otherwise, it looks ok on ~sparc.  Will keyword once we figure out the above.

Narf, bugzie swallowed my comment:
i changed the library name, b/c lua-5.0.3 came with liblualib, but seeing they
also got a liblua i've reverted to the original behaviour of calling the
library liblua.*
I also tested the not in tree ion3 w/ it, compiles quite fine.

Whoops.
I just opened bug 158460 which looks like it pertains to this.
Basically, imapfilter is looking for both liblua and liblualib.
With 5.1.1, we only get liblua and the emerge of imapfilter fails.
Whoever is working on this bug may want to take a look at imapfilter also.

liblualib and liblua are quite the same actually. liblualib just adds in more
libs (libm, readline, dl, et. al) if i read the Makefile correctly. All that is
now provided with liblua.
Upstream only provides liblua as of my knowledge. This issue is really
upstream, and i'll write to them tomorrow. Short term action would be to patch
the Makefile they provide or (which i'd find kinda ugly) symlinking of
liblua.so to liblualib.so via the lua ebuild.
But personally, i'd suggest fix the packages.

Just adding a note about the 5.1.1's liblua+liblualib issue is more dangerous
than it seems, for example on lua enabled kde the missing liblualib.so.5.0
and/or liblua.so.5.0 (note the final zero) breaks fatally editor kpart, causing
unidentifiable crash for kate session startup, nonfunctionality of kdevelop and
partial nonfunctionality of konqueror. Reemerging kdelibs-3.5.5-r7 manually was
a good fix for me, so I can keep lua-5.1.1 for other esoteric purposes.
However, revdep-rebuild was of no help in this case. (This comment is meant to
contain all the relevant keywords to point other searchers this way.)

Here we go: the shiny new, absolutly beautiful *cough* slotted lua has arrived
in the tree. The good news is: you now can keep two APIs around, so your
programs are all fine, while you try out new shiny stuff.
Here's the dark side of it: i'm still trying to figure out how programs can
keep to use -llua in their compiles and it will just work[tm]. Currently, due
to both lua librarys being installed in parallel, none of them gets the
liblua.* slot, which most apps will look out for.
Till i've figured out how to release the beast w/o breaking everyones system,
it remains in the cage that is package.mask.
However, if you're brave enough, test them out and give 'em some keyword love.
The librarys are still fine, it's just their interface to the outside world
that sucks hard.

portage/dev-lang/lua/files/lua-5.1.1-Makefile.patch

was broken as of my --sync last night... the two patch chunks have different
relative directories.  The relative directories in each chunk have to match.  I
suppose the two chunks were manually stuck together in the same file.

( the patch is only used by lua-5.1.1-r1 which is hard-masked )

I'm now officially unsure if adding the slotted luas was that a good idea at
all. Seems we can get lua-5.1.1 supported in the tree w/o backwards
compatibility issues. In plain english: i'm almost sure we can update any lua
using app in the tree to use lua-5.1.1 thus obsoleting the need for lua-5.0*.
I've therefore removed the slotted versions (lua-wrapper will follow in a bit)
from the tree.

Arches: please consider marking dev-lang/lua-5.1.1 ~arch. I'll see to the
broken apps together with their maintainers and committing fixes as i have
them.

I tryed to compile lua 5.1.1 on amd64 and it compiled. What do u think about
adding ~amd64 to ebuild.

I confirm successful compilation on amd64 .

(In reply to comment #13)
> I confirm successful compilation on amd64 .
> 

ditto, added ~amd64

~sparc'd

alpha, arm, ia64, mips: I have removed your ~arch keywords on
=www-servers/lighttpd-1.4.13* until you have lua-5.1* keyworded.
When you add yourself back to lua, add yourself to lighttpd-1.4.13* as well.

alpha, arm, ia64, mips: reping, you are missing out out the lighttpd goodness
because of this bug.

~ia64 has now lua and lighttpd.

Comment #8 is really important. 
What about ~x86?
Synced tree and updated system pulled in 5.1.1-r2 lua and my kde* parts which
use them are broken now, missing the liblualib.so.
Manually creating the symlink does help but this is not a fix.

Any thoughts about x86?

(In reply to comment #19)

> Synced tree and updated system pulled in 5.1.1-r2 lua and my kde* parts which
> use them are broken now, missing the liblualib.so.

Can you elaborate on what parts exactly are broken and how i can reproduce?
The liblualib.so is *gone* in 5.1 and nothing i can/will do about it. Anything
depending on it to be there is not 5.1 ready.

~alpha done. Sorry for the delay.

- ferdy

To all slackers: lua-5.1.2 is out, fixing bugs from the previous release.
Please keyword it.

Hey mips team, i'm kinda stuck with lua-5.0* if you don't keyword and stable
anything 5.1* in the future.

This bug is over a year old. Please give some love to the newly comitted 5.1.3
and the 5.1.2 version, as that's going stable soon enough.

Thanks.

Keywording continues at another bug as this isn't about keywording 5.1.2
anymore.

*** This bug has been marked as a duplicate of bug 222243 ***