FS#18647 - [luarocks] arch=('any') is not appropriate for this package

Attached to Project: Community Packages
Opened by James Snyder (jbsnyder) - Friday, 12 March 2010, 03:45 GMT
Last edited by Chris Brannon (cmb) - Saturday, 13 March 2010, 01:50 GMT
Task Type Bug Report
Category Packages
Status Closed
Assigned To Chris Brannon (cmb)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:
luarocks package should not be built as arch=('any') since building it on i686 or x86_64 will change the flags that it will use when compiling rocks. Attempting to use the builtin module builder with luarocks will lead to complaints on compilation about -fPIC needing to be set.

The Debian package has had the same problem:
http://lists.luaforge.net/pipermail/luarocks-developers/2010-February/001438.html

I assume the fix would be to set arch=('i686' 'x86_64') to require that the package be generated for each platform correctly.

Additional info:
* luarocks-2.0.1-2-any


Steps to reproduce:
1. install luarocks package on x86_64 machine
2. sudo luarocks install luafilesystem
This task depends upon

Closed by  Chris Brannon (cmb)
Saturday, 13 March 2010, 01:50 GMT
Reason for closing:  Fixed
Comment by Chris Brannon (cmb) - Friday, 12 March 2010, 14:39 GMT
Oh, nice.
There's one line of lua code preventing this package from being
architecture-independent. I changed the architecture, and I built
both an i686 and an x86_64 package. I extracted those packages
to temporary directories, and I ran a recursive diff. It's attached.
The .PKGINFO diff isn't included, since we don't care about that.

Comment by James Snyder (jbsnyder) - Friday, 12 March 2010, 16:36 GMT
That sounds about right, presumably it could be an any package that just fixes those lines in that config.lua:
http://lists.luaforge.net/pipermail/luarocks-developers/2010-February/001443.html

It doesn't sound as if the LuaRocks team itself intends to support being installed from a binary package as platform generic without those types of post-install modifications.
Comment by Chris Brannon (cmb) - Friday, 12 March 2010, 18:24 GMT
Yes, I could patch at install-time, but I don't like doing that. It
isn't robust. It is one more thing that could be broken by
a future release.
So I think I'll just make the package architecture-dependent.
The tarball is only 63k or so, anyhow.

Thank you very much for your helpful report!

Loading...