Bug#827590: RFS: lua-torch-trepl/0~20160613-g06128f9-1 [ITP]

[Lumin <cdluminate@gmail.com>]

Hi,

updated the lua-torch-trepl package, including the change of release
to experimental.

https://mentors.debian.net/package/lua-torch-trepl

it passed debomatic-amd64 build:

http://debomatic-amd64.debian.net/distribution#experimental/lua-torch-trepl/0~20160613-g06128f9-1/buildlog

Concerning the readline.so problem, if this library is split into
another package, then what name the package should take becomes a
problem. Since it installs a symlink

  File: '/usr/lib/x86_64-linux-gnu/lua/5.1/readline.so' -> 'treplutils.so'

which means it can't use the `lib*` namespace. Moreover, it is
confusing if shipped in a `libtorch-readline` package (libtorch-th
ships /usr/lib/x86_64-linux-gnu/libTH.so.0). Oh what about
lua-torch-trepl-readline ? but this package used `lua-*` namespace and
ships no lua file.

with command [1] and [2] and [3] a readline.so can be separately
generated but I think there is no much need, although not elegant. 1.
I don't know how to name the package shipping only that symlink. 2.
lua loads symbols dynamically, such symlink won't harm functionality.

Well, that's the reason why I didn't change the readline.so symlink.
Please comment, thanks.

[1] libtool --silent --tag=CC --mode=compile cc -c -g -O2
-fdebug-prefix-map=/home/lumin/hdd/debian/torch.set/lua-torch-trepl.pkg/lua-torch-trepl=.
-fPIE -fstack-protector-strong -Wformat -Werror=format-security
-Wdate-time -D_FORTIFY_SOURCE=2 -I/usr//include/lua5.1
-I/home/lumin/hdd/debian/torch.set/lua-torch-trepl.pkg/lua-torch-trepl
-Wall -Wextra -o
/home/lumin/hdd/debian/torch.set/lua-torch-trepl.pkg/lua-torch-trepl/5.1-torch-trepl/readline.lo
readline.c

[2] libtool --silent --tag=CC --mode=link cc \
    -rpath /usr//lib/x86_64-linux-gnu -version-info 0:0:0 -Wl,--no-add-needed \
-o /home/lumin/hdd/debian/torch.set/lua-torch-trepl.pkg/lua-torch-trepl/5.1-torch-trepl/liblua5.1-torch-trepl.la
\
    /home/lumin/hdd/debian/torch.set/lua-torch-trepl.pkg/lua-torch-trepl/5.1-torch-trepl/utils.lo
/home/lumin/hdd/debian/torch.set/lua-torch-trepl.pkg/lua-torch-trepl/5.1-torch-trepl/readline.lo
\
-fPIE -pie -Wl,-z,relro -Wl,-z,now
-L/home/lumin/hdd/debian/torch.set/lua-torch-trepl.pkg/lua-torch-trepl
-lreadline

[3] ln -sf ./.libs/liblua5.1-torch-trepl.so.0.0.0 \
/home/lumin/hdd/debian/torch.set/lua-torch-trepl.pkg/lua-torch-trepl/5.1-torch-trepl/treplutils.so

On 7 August 2016 at 16:16, Lumin <cdluminate@gmail.com> wrote:
> On 4 August 2016 at 18:42, Gianfranco Costamagna
> <locutusofborg@debian.org> wrote:
>
>> why do not build-depend on the dev package?
>> I'm talking about "lua-torch-torch7"
>
> This is due to, actually "trepl" doesn't B-D on the "lua-torch-torch7-dev"
> package. It is a runtime dependency. I'll leave a comment there.
>
> Keeping this runtime B-D there because it declares explicit dependency
> relationship.
>
>> also, there is some sadness in the libreadline.so link, are you sure there is no better way to fix that?
>> what about a package split?
>
> I've thought about spliting it up -- inspece verbose dh build and
> extract the library compilation commands into d/rules -- however this
> makes d/rules complicated with hardcoded compiles.
>
> Seems that dh_lua didn't foresee such a demand, so the above method is
> the way first came up in my mind.
>
> Now that the symlink just works fine ...
>
> 1. split then up with hardcoded compile
> 2. create a new package that ships just a simlink
>
> How do you like it?
>
>> cheers,
>>
>> G.
>
>
>
> --
> Best,
> Lumin



-- 
Best,
Lumin