From Fedora Project Wiki
(RHEL 6 lua doesn't provide virtual provide lua(abi))
 
(4 intermediate revisions by 3 users not shown)
Line 8: Line 8:
  
 
== Macros ==
 
== Macros ==
Define the following on top of your spec file:
+
 
 +
 
 +
Starting with Fedora 24, the following macros for packaging lua extensions are provided by the <code>lua-devel</code> package:
 +
 
 +
{|
 +
|-
 +
! Macro        !! Description
 +
|-
 +
| %lua_version  || version of system installed lua
 +
|-
 +
| %lua_libdir  || installation directory for compiled modules
 +
|-
 +
| %lua_pkgdir  || installation directory for arch-independent modules
 +
|-
 +
| %lua_requires || declares the needed runtime dependencies for the binary package
 +
|}
 +
 
 +
 
 +
{{admon/caution|EPEL ONLY|This is for EPEL only.  Fedora provides the packaging macros above.  There are chances those macros might get backported to EPEL.}}
 +
 
 +
 
 +
Define the following macros on top of your spec file:
  
 
<pre>
 
<pre>
%global luaver 5.1
+
%{!?lua_version: %global lua_version %{lua: print(string.sub(_VERSION, 5))}}
 
# for compiled modules
 
# for compiled modules
%global lualibdir %{_libdir}/lua/%{luaver}
+
%{!?lua_libdir: %global lua_libdir %{_libdir}/lua/%{lua_version}}
 
# for arch-independent modules
 
# for arch-independent modules
%global luapkgdir %{_datadir}/lua/%{luaver}
+
%{!?lua_pkgdir: %global lua_pkgdir %{_datadir}/lua/%{lua_version}}
 
</pre>
 
</pre>
  
From Fedora 16 and onwards (not RHEL 6!), the main <code>lua</code> package virtually provides <code>lua(abi) = %{luaver}</code>, so packages targeting this release and above can declare this runtime dependency:
 
 
<pre>
 
Requires: lua(abi) = %{luaver}
 
</pre>
 
  
to target older releases (or RHEL 6), use the following instead. It's less safe (in that RPM will not complain if you install this package on a system with a higher Lua ABI version) but in practice our supported releases currently ship with Lua 5.1.x.
+
To make the package pull the correct runtime dependencies, declare them like this:
  
 
<pre>
 
<pre>
Requires: lua >= %{luaver}
+
%if 0%{?fedora} >= 16 || 0%{?rhel} >= 7
 +
Requires: lua(abi) = %{lua_version}
 +
%else
 +
Requires: lua >= %{lua_version}
 +
Requires: lua <  %{lua: os.setlocale('C'); print(string.sub(_VERSION, 5) + 0.1)}
 +
%endif
 
</pre>
 
</pre>
  

Latest revision as of 14:18, 28 May 2017

Naming

(This section should eventually be linked from Packaging:NamingGuidelines)

Lua add-on packages generally follow the naming scheme of lua-modulename -- e.g. lua-filesystem, lua-lpeg, lua-moonscript. If the module name makes it clear that it is an add-on for Lua, though, the module name itself is sufficient. e.g. lutok.

Use your judgement -- e.g. the second l in lua-lpeg already stands for Lua, but it might not be seen as unambiguous enough.


Macros

Starting with Fedora 24, the following macros for packaging lua extensions are provided by the lua-devel package:

Macro Description
%lua_version version of system installed lua
%lua_libdir installation directory for compiled modules
%lua_pkgdir installation directory for arch-independent modules
%lua_requires declares the needed runtime dependencies for the binary package


Stop (medium size).png
EPEL ONLY
This is for EPEL only. Fedora provides the packaging macros above. There are chances those macros might get backported to EPEL.


Define the following macros on top of your spec file:

%{!?lua_version: %global lua_version %{lua: print(string.sub(_VERSION, 5))}}
# for compiled modules
%{!?lua_libdir: %global lua_libdir %{_libdir}/lua/%{lua_version}}
# for arch-independent modules
%{!?lua_pkgdir: %global lua_pkgdir %{_datadir}/lua/%{lua_version}}


To make the package pull the correct runtime dependencies, declare them like this:

%if 0%{?fedora} >= 16 || 0%{?rhel} >= 7
Requires: lua(abi) = %{lua_version}
%else
Requires: lua >= %{lua_version}
Requires: lua <  %{lua: os.setlocale('C'); print(string.sub(_VERSION, 5) + 0.1)}
%endif

Rocks

Upstream Lua developers increasingly use LuaRocks to distribute their modules. We are exploring providing better integration with LuaRocks in the future -- both in generating spec files from .rockspec specifications, and in shipping a luarocks package that can pick up existing RPM-installed Lua packages, but for the time being, you can use upstream rockspec specifications to guide your packaging work.