Re: More about packaging

["Hisham H. Muhammad" <hisham@...>]

On Friday 04 June 2004 05:58, Diego Nehab wrote:
> Hi,
>
> I am in the process of defining how LuaSocket is to be packaged.

Speaking from a distro maintainer standpoint, that's very good to hear. I 
packed LuaSocket 2.0-alpha for GoboLinux, and had a hard time getting it 
right, but finally got to the point where one can:

prompt] Compile Lua
-- GoboLinux Compile script downloads,
-- compiles and installs Lua
prompt] Compile LuaSocket
-- GoboLinux Compile script downloads,
-- compiles and installs LuaSocket
prompt] lua
Lua 5.0.2  Copyright (C) 1994-2004 Tecgraf, PUC-Rio
> require("luasocket")
> socket.sleep(10)
>

To achieve this I had to include a patch to the Makefile in the compilation 
script. (the specific patch is stored in 
http://gobolinux.org/recipe-store/LuaSocket--2.0-alpha--recipe.tar.bz2
if it's of any interest).

The final layout of files was this:

/Programs/LuaSocket
/Programs/LuaSocket/2.0-alpha
/Programs/LuaSocket/2.0-alpha/Resources
/Programs/LuaSocket/2.0-alpha/Resources/Environment
/Programs/LuaSocket/2.0-alpha/lib
/Programs/LuaSocket/2.0-alpha/lib/libluasocket.so.2.0
/Programs/LuaSocket/2.0-alpha/lib/luasocket
/Programs/LuaSocket/2.0-alpha/lib/luasocket.lua
/Programs/LuaSocket/2.0-alpha/include
/Programs/LuaSocket/2.0-alpha/include/luasocket.h
/Programs/LuaSocket/2.0-alpha/doc
/Programs/LuaSocket/2.0-alpha/doc/README
/Programs/LuaSocket/2.0-alpha/lua.lua
/Programs/LuaSocket/Current -> 2.0-alpha

The pathname peculiarities of the GoboLinux can be disregarded, as it can be 
simply considered an installation with an arbitrary $prefix. One peculiarity, 
however, I'd like to be considered: in GoboLinux each program is installed 
under its own $prefix and I would find very desirable if LuaSocket (and other 
Lua extensions) did not require to be installed under the same $prefix as 
Lua. In a regular Unix system, one could consider a scenario where Lua is 
installed with a distro-provided package under /usr and the site sysadmin 
wishes to install LuaSocket in /usr/local.

To work around this in LuaSocket, you can see I dumped lua.lua in 
$(INSTALL_LUASOCKET) instead of $(INSTALL_LUA). Reading your post I realized 
that this way I'm not using your modified loadlib (and that's why I had to 
create that ugly 'luasocket -> libluasocket.so.2.0' under /lib).

BTW, I'm a newbie to Lua: "who" is supposed to run lua.lua? If I can get 
lua.lua to run, then I can just define LUA_LIBNAME in LuaSocket's 
Resources/Environment entry and not use the no-extension symlink. A feature 
request: LUA_LIBNAME should accept multiple semicolon-separated entries, like 
LUA_PATH, so that multiple Lua extensions may be installed under different 
$prefixes and just append to LUA_LIBNAME.

Another question: doesn't the modified loadlib clash when other libraries 
expect the default behavior? I've seen code like this (in ALua, for instance) 
-- 'luadirectory' is an absolute pathname:

channel.lua:24:require (luadirectory .. "/luasocket/luasocket")
channel.lua:27:require (luadirectory .."/luaTimer/luatimer")
start_daemon.lua:29:require (luadirectory .. "/luasocket/luasocket")

I find this usage of require unfortunate, and I believe the kind of behavior 
you propose for loadlib is the ideal not only in terms of 
platform-independence, but also in path-agnosticism, which in the 
heterogeneous universe of Linux distributions, is just as important.

-- Hisham