Date: Wed, 26 Jun 2013 17:38:11 -0400
From: Dubiousjim <lists+alpine-devel@jimpryor.net>
To: alpine-devel@lists.alpinelinux.org
Cc: Natanael Copa <ncopa@alpinelinux.org>
Subject: Re: [alpine-devel] upgrading to Lua 5.2
Message-ID: <20130626213811.GB18572@zen>
Mail-Followup-To: alpine-devel@lists.alpinelinux.org,
	Natanael Copa <ncopa@alpinelinux.org>
References: <20130619160141.25d3702e@ncopa-desktop.alpinelinux.org>
Precedence: list
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20130619160141.25d3702e@ncopa-desktop.alpinelinux.org>
User-Agent: Mutt/1.5.21 (2010-09-15)

On Wed, Jun 19, 2013 at 04:01:41PM +0200, Natanael Copa wrote:

> I have been looking at upgrading to Lua 5.2. Many things is just a
> question of recompile and some needs porting...

Hi Natanael, I'll definitely help with porting things to Lua 5.2, though
it may be a few weeks before I can get into it.

> Those failed and still need some work:
> 
> vlc
> squark
> rrdtool
> lighttpd
> kamailio
> tolua++
> conky
> cegui06
> 
> Some of them looks non-trivial, like squark.
> 
> I asked in #lighttpd and there was some resistance from upstream to
> port the stable lighttpd to lua 5.2 as it risks to break users scripts.

That's too bad. Not surprising that some upstreams are going to have
that position, though. I doubt they'll be the only ones.

Maybe I can port lighttpd's buildsystem to honor a --with-luafiveq flag,
and if built in that way, to work with either Lua 5.1 or Lua 5.2 on the
host system, and load user scripts in such a way as to be maximally
compatible with both. Then we can try to persuade the upstream guys to
test that, and if they like it, to roll it in. It'd be a good test case
for luafiveq. I use lighttpd anyway (but not atm any lua scripts for
it). I'll put this on my mental queue of things to do when I can.

> Now, I am still a bit in doubt how we move forward. I think we have the
> following options:
> 
> One shot upgrade
> One shot upgrade, with partial 5.1 compatibility
> Append 5.2 and migrate slowly over
> Support both versions in parallel
> ...
>
> What do you think? I think I'd prefer one of the 2 options in the middle.
> 
> In any case, porting to 5.2 will require pretty much work so I think
> I'd like to get more people involved and start help with that as soon as
> possible.

I'd incline towards one of the middle options also. Perhaps a backend
where there are lua51-foo and lua52-foo packages (installing to
/usr/{lib,share}/lua5{1,2} directories), and a lua-foo metapackage that
just depends on one of those. That makes for more manual work for those
working on the packaging, but I don't think it'll be too bad.

Like Arch did when they made Python 3.x their default python, we can
just make sure that any apk-installed lua scripts use:
    #!/usr/bin/lua51
instead of:
    #!/usr/bin/lua
.

Then we might push option 3 first, and once that's working cleanly we
can step back and assess when is the right time to shift all the lua-foo packages to
depend on lua52-foo instead of lua51-foo. Actually implementing that
change will then be trivial. But we'd have gotten some broad testing in
beforehand, from users who try out lua52-foo directly.

> Drawbacks:
>   ...
>   We get same problem when 5.3 comes out.

I wouldn't worry about that. Have a look at
<http://www.lua.org/versions.html>. Should be many years.

As you also observed, it'd be a lot of packages. This is a downside, but
seems a minor one to me.


Here are some more detailed suggestions:

One git commit (or set of commits): all folders lua-foo in aports moved to lua51-foo, and
all references to lua-foo in any APKBUILD also so modified; at the same
time, lua51-foo gets a release bump. Same with the base "lua" package.

(It looks from some recent aports commits like you're starting to do
something along these lines. I haven't looked closely yet, though.)

Second git commit(s): add new folders lua-foo, with APKBUILD having same
version/release as lua51-foo, and simply depending on lua51-foo. The
idea is that no package will refer to lua-foo, this is just for "apk add
lua-foo". Same with the base "lua" package.

Those two (sets of) commits could then be pushed out.

Third commit(s): /usr/{share,lib}/lua moved to /usr/{share,lib}/lua51, all
affected APKBUILDs and Makefiles adjusted to suit; all those packages
get a release bump.

Fourth commit(s): Make base "lua51" package install binaries at
/usr/bin/lua51, and symlink to that with /usr/bin/lua; also gets a
release bump. Also, any package that installs a #!/usr/bin/lua script has
that changed to say #!/usr/bin/lua51, and gets a release bump.

Fifth commit: add lua52 package.

Sixth commit(s): start copying lua51-foo packages to lua52-foo, and
building/installing for lua52.

Down the road:
* Application packages that depend on lua, like lighttpd,
might be rebuilt with lua52, and change their dependencies accordingly. 
* lua51 no longer installs the symlink /usr/bin/lua, instead lua52 does
this (or neither does it, user does it him/herself).
* lua-foo packages start depending on lua52-foo instead of lua51-foo.

Way down the road:
* lua51 and all the lua51-foos get dropped. I'd just leave the
lua-foo/lua52-foo infrastructure in place, though. A bunch of extra
folders in the package tree don't hurt much. Main downside is that
whenever you version-bump one of them, you'd have to remember to bump
both.

-- 
Dubiousjim
dubiousjim@gmail.com


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---