[aur-general] TU application: Daurnimator

[Eli Schwartz]

On 12/11/18 3:00 PM, Daurnimator wrote:
> On Tue, 11 Dec 2018 at 11:45, Alad Wenter via aur-general
> <aur-general at 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.archlinux.org/pipermail/aur-general/attachments/20181211/29ece725/attachment.asc>