Hi,
I have been looking at upgrading to Lua 5.2. Many things is just a
question of recompile and some needs porting.
So far, those have been rebuilt/ported against 5.2 in a local branch:
apache2
apk-tools
asterisk
awesome
gegl
graphviz
haserl
lsyncd
nmap
ntop
pingu
pllua
sircbot
vim
weechat
lua-augeas
lua-cjson
lua-filesystem
lua-microlight
lua-posix
lua-socket
I haven't verified if all of them runs.
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.
Then there are a bunch of modules that I have not yet looked at:
lua-cmsgpack
lua-curl
lua-dbi
lua-discount
lua-expat
lua-iconv
lua-imlib2
lua-ldap
lua-lgi
lua-llthreads
lua-md5
lua-openrc
lua-pc
lua-posixtz
lua-pty
lua-rex
lua-sec
lua-signal
lua-sleep
lua-sql-mysql
lua-sql-postgres
lua-sql-sqlite3
lua-stdlib
lua-stringy
lua-subprocess
lua-uuid
lua-xctrl
lua-xml
lua-yaml
lua-zlib
lua-zmq
I think some of those will just work, if they only gets installed in
proper dir. Some will require minimal a bit of porting.
Then we have the entire acf-*. I think it will be fairly easy to port
those. They are just many.
Now, I am still a bit in doubt how we move forward. I think we have the
following options:
One shot upgrade
================
We upgrade lua package to 5.2.x and port/upgrade everything in a
(local) git branch. Once everything is done we push. For things that is
difficult to port we can use luafiveq.
At that time evertying is over to Lua 5.2.
Benefits:
once done, we save us for maintaining both lua 5.1 and 5.2 in
parallel.
We will only have one Lua.
Drawbacks:
difficult to let many help in doing it. Until everything is done, the
only lua version available will be lua 5.1. How are developers
supposed to be able to help?
Users will not be able to upgrade to alpine v2.7 until they are ready
for Lua 5.2.
We get same problem when 5.3 comes out.
One shot upgrade, with partial 5.1 compatibility
================================================
We upgrade lua to 5.2 and provide a lua5.1 package for backwards
compat. We could use luafiveq for those who are difficult to port and those who cannot use that either can rebuild against lua5.1-dev.
Benefits:
less maintenance than supporting both. It gives developers a chance
to get started to migrate to 5.2.
Drawbacks:
We might need to support some of the modules (lua-*) both for 5.1 and
for 5.2 for some time. We need rename all the 5.1 modules to lua5.1-*.
Users will not be able to upgrade to alpine v2.7 until they are ready
for Lua 5.2. (or have to manually install/change to use lua5.1 while
upgrading)
We get same problem when 5.3 comes out.
Append 5.2 and migrate slowly over
==================================
Add a new package named lua5.2. and rebuild the easy apps against
lua5.2. The package named 'lua' will still be lua-5.1. Ported/upgraded
modules will be be prefixed with 'lua5.2-'.
Benefits:
we don't need big onetime commits which depends on one person or one
big branch.
Developers can install lua5.2 and start port stuff fairly early.
Smoother upgrades for end users (hopefully). The packages are not
suddenly renamed so local user scripts does not suddenly break.
Might make it easier when 5.3 comes out since we can do similar then.
At that time we can evaluate to delete the 5.1.
Drawbacks:
Simply 'apk add lua' will give old lua so it kind of encourage
endusers to stay on old which gives us more maintenance in the long
run.
We might not be able to have both 5.1 and 5.2 installed at the same
time so it might cause more package conflicts. (what should
/usr/bin/lua point to?)
Support both versions in parallel
=================================
Rename all current lua-* to lua5.1-* and rebuild all current against
that. Then add lua5.2 and port things slowly over. Support both as long
as it makes sense.
Benefits:
Users can at any time choose 5.1 or 5.2 or have both installed at the
same time.
Developers can start port stuff and test on both.
Makes a future 5.3 easier.
Drawbacks:
Lots of work.
More maintenance work. We might end up with +50 packages if not more.
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.
-nc
---
Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org
Help: alpine-devel+help@lists.alpinelinux.org
---
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
---
On Wed, 26 Jun 2013 17:38:11 -0400
Dubiousjim <lists+alpine-devel@jimpryor.net> wrote:
> 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.
I figured. So it means that the only sane way forward is to support both 5.1 and 5.2 in parallel.
> 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.
I think we could just port it to 5.2, and maintain a patch. The patch
could be posted in lighttpd's bugtracker/wiki so others could test it
too.
> > 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> 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> .
This is what i originally wanted but i realized that it would break
things for users. (python broke things for arch users too)
> 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.
Thats what I thought when i built first Lua (5.1) packages :)
> 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.
I dropped those 4 commits for now and just added lua5.1 (and
lua5.1-dev). I added a symlink package named 'lua' that for now only
pulls in lua5.1 and creates symlinks /usr/lib/pkgconfig/lua.pc ->
lua5.1.pc and /usr/bin/lua -> lua5.1
This was so that nothing existing breaks. Once we have ported most
stuff to lua5.2 we could point the lua symlinks to the 5.2.
> Fifth commit: add lua52 package.
I added a package named lua5.2 instead of lua52. I must admit i liked
lua52 better but we have similar names for libcrypto1.0, goffice0.8 etc
so we better try stay consequent.
> > Sixth commit(s): start copying lua51-foo packages to lua52-foo, and> building/installing for lua52.
This is where I am now. I am copying lua-foo to lua5.2-foo in testing.
> Down the road:> * Application packages that depend on lua, like lighttpd,> might be rebuilt with lua52, and change their dependencies accordingly.
Yes. I think the packages I managed to rebuild against 5.2 so far
should be fairly easy.
> * lua51 no longer installs the symlink /usr/bin/lua, instead lua52 does> this (or neither does it, user does it him/herself).
What we will do is just update the 'lua' package that currently depends
on lua5.1 and has symlinks pointing to lua5.1 files to depend on lua5.2
and point the symlinks accordingly.
At this point we should probably rebuild the stuff that depends on
'lua' (5.1) so the depend on 'lua5.1' instead.
> * 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.
I think we will have to maintain both for a while :-/ unless ACF devs
start porting to lua 5.2.
Thanks for your feedback!
-nc
---
Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org
Help: alpine-devel+help@lists.alpinelinux.org
---