[Slackbuilds-users] conky doesn't build LONGER

Duncan Roe duncan_roe at optusnet.com.au
Tue Nov 21 21:38:30 UTC 2017

On Mon, Nov 20, 2017 at 12:47:24PM -0500, B Watson wrote:
> On 11/20/17, Matteo Bernardini <matteo.bernardini at gmail.com> wrote:
> > - parallel install different lua versions;
> > - checking that the various things that need those find the right one
> > in each case.
> > ...but this solution is really hard to implement, as the script being
> > involved are =~ 150 and they have to be all tested working to
> > implement it on the repository.
> > if someone feels like doing this work it would be highly appreciated.
> Looks like a lot of stuff links with lua's shared libs. I'd say,
> keep things exactly as they are for lua 5.1, and add a lua53 build
> that installs version 5.3 to a different prefix (maybe /opt/lua-5.3),
> and doesn't install anything *at all* in /usr (except for /usr/doc/
> I suppose), so there's no chance of conflict.
> The lua53 build could also include a script, *disabled by default*,
> that sets $PATH and whatever else lua uses, with instructions in the
> README explaining how to source that script in .bash_profile. So if you
> want your user account to use lua-5.3 when you run a script that says
> "#!/usr/bin/env lua", you can, but root won't be set up that way. A
> script that says "#!/usr/bin/lua" will always run lua-5.1 though.
> Doing it that way, everything that currently uses lua 5.1 should continue
> to work as-is. Anything new that needs lua-5.3 will need to explicitly
> set the paths when building (maybe --with-lua=/opt/lua-5.3 or such,
> if it uses autotools), including -Wl,-rpath or whatever's needed to
> get the correct libs linked. SlackBuild scripts could also source the
> abovementioned environment script, if that would help.
> Once this is working, those 150 lua-using builds can slowly be tested
> against 5.3, and fixed/patched as needed. Or not: why bother? Working
> scripts are working scripts. Unless switching a script to use lua-5.3
> actually makes the built package more useful to end-users, what would
> be the point?
> Disclaimer: I know very little about lua. The only reason it's impinged
> on my awareness is that mame uses it... but it has to build its own
> lua-5.3 from bundled sources, because it can't use 5.1. The rest of
> mame's build system is actually written in lua, I'd love it if things
> could be arranged so that mame could use a pre-existing lua 5.3 install.
> The only game-changer here would be if Pat someday decided to include
> lua in core Slackware. No idea if that's likely, so no point worrying
> about it now.

If liblua.so has been bunped to liblua.so.6.x.y, then from a runtime point of
view it should be all right to install as standard. If not, report to upstream
as a bug.

What must not happen is for upgradepkg to remove liblua.so.5.

That could be achieved by having a new package say lua53, or having lua build
liblua.so.5 as well as liblua.so.6 (needs 2 tarballs: could have a COMPAT option
to not build old library).

Either way that should allow gentle migration, or am I missing something?

Cheers ... Duncan.

More information about the SlackBuilds-users mailing list