On 12/11/18 3:00 PM, Daurnimator wrote:
On Tue, 11 Dec 2018 at 11:45, Alad Wenter via aur-general <aur-general@archlinux.org> wrote:
1. When I look at LUA modules, I see that most are available on "luarocks", which is apparently a package manager for LUA. Can you leverage this to make more LUA modules available on Arch?
Note that it's "Lua" not LUA.
I'd like to leverage luarocks to build lua packages, however it maintains its own local database of installed packages which makes things awkward. I don't want to introduce luarocks as a non-build-time dependency. Follow https://github.com/luarocks/luarocks/issues/671 for possible progress in this area.
So I looked at this link of yours and all I see is the luarocks maintainer asking in the very first response, why not just use luarocks to build the package and just discard the database. I'm not even seeing why such a database database is awkward though. I can think of two analogues: python setuptools packages install egg-info metadata which is hardly required to execute the python code, but does allow setuptools itself to build a runtime index of available modules haskell's ghc-pkg stores the same sort of metadata in /usr/lib/ghc-8.6.3/package.conf.d/ but additionally has a binary cache of this database, that is updated with the contents of non-core packages by a pacman PostTransaction hook. What harm or "awkwardness" is caused by lua packages installing optional metadata that doesn't require luarocks to be installed? Are you saying that merely building a lua package with luarocks will cause the package to import the luarocks module during initialization and error out if it isn't installed?
2. You have some AUR packages for LUA modules of your own making, yet they hardcode gcc lines instead of using a Makefile. [1] (At least they respect $CFLAGS and $LDFLAGS, I guess.) Why?
The upstream packages do not ship a makefile; they "officially" only support luarocks for building. Due to the above-mentioned issue, I don't see it as feasible to use luarocks for AUR packages at the moment, so I had to hard-code the build commands into the PKGBUILD.
3. I have no idea on what some of your more complicated packages do, or why they would require said complexity, e.g. iup. [2] Perhaps you could explain a bit on that regard.
IUP is a graphical toolkit similar to gtk, qt or wxwidgets with many components. The upstream do not want to support dynamic linking for some pieces, so I need to patch out their (custom) build system 'tecmake'.
The release tarballs include lua bindings to the C IUP library; some complexity in the PKGBUILD comes from compiling necessary components for each of lua 5.1, 5.2 and 5.3.
4. Related to the above, there are no current packaging guidelines for LUA packages. [3] Do you plan on starting an effort (possibly with other LUA package maintainers) to remedy this?
Yes :) If anyone would like to help out with this I'm all ears.
As someone who has never touched lua in my life (other than googling for their Makefile to try to figure out the public pkg-config interface it provides), I think the first step is to try to work with lua upstream, because if this discussion is a sign of what packaging guidelines would look like, then you'd need to first convince me why it is right and just, and only then tell me how to do it. I'm now far more confused about how to package lua than I was before this thread -- and I used to not know anything! -- Eli Schwartz Bug Wrangler and Trusted User