Lua Policy
Правила упаковки модулей и программ на языке Lua.
Список интерпретаторов Lua в ALT Linux
- Lua 5.1
- Lua 5.3
- LuaJIT 2.1 (совместим с Lua 5.1)
Для ясности стоит также упомянуть, что:
- фактически транслятор языка находится в библиотеке и предоставляется пакетами liblua5.x и libluajit
- программа /usr/bin/lua из пакета lua5.x является только средством для запуска скриптов Lua и чистых-Lua-программ (как тот же LuaRocks).
- каждая из веток (5.3 и 5.1) у нас независимы от интерпретатора до дерева модулей. Ситуации, когда зависимости пакетов пересекают границы веток, считаются ошибкой.
Общие соображения
Программы Lua могут исполняться в двух режимах:
- Какая-то программа, которая содержит в себе интерпретатор Lua (например, в виде библиотеки liblua.so.*), запускает Lua-подпрограмму посредством этого интерпретатора
- Скрипт Lua запускается с помощью программы-интерпретатора, /usr/bin/lua
Следовательно, всё-таки стоит отойти от практики явной линковки модулей Lua с liblua.so и воспринимать эту библиотеку не как библиотеку, а как интерпретатор.
Модули Lua (как чистые-Lua, так и *.so) следует паковать через LuaRocks. Это позволяет полуавтоматически отслеживать зависимости между модулями и, в крайнем случае, доустанавливать модули пользователям в локальном режиме.
О версиях Lua и их модулях
Давным-давно в ALT Linux была одна только Lua 5.0 . С тех пор у нас стандартными путями для модулей были %_datadir/lua5 и %_libdir/lua5 . Потом вышла Lua 5.1 и версию 5.0 выкинули. Сейчас у нас 3 интерпретатора, реализующих две версии языка: 5.3 и 5.1 . Одним из критичных вопросов примем вопрос востребованности (интерпретаторов, модулей, ...).
- Понятно, что каждый из интерпретаторов востребован теми пакетами, которые от них зависят, как какой-нибудь love работает на libluajit.so, поэтому в его зависимостях это прописано явно
- Для модулей у нас есть зависимости их друг от друга и от версии Lua (пример?). Вопрос востребованности (т.е. вопрос: для какой версии Lua нужны модули?) открывается очень простым. На самом деле в 95% случаев подходит Lua >= 5.1. Это позволяет принять версию 5.3 главной в вопросе поддержки модулей и их упаковки.
- Необходимо сохранить возможность упаковки модулей для определённых версий Lua, а также обеспечить максимальное облегчение сборки таких модулей
Главная версия
Главной версии интерпретатора у нас не будет, версии работают независимо
Правила упаковки модулей Lua
Модули и Lua-библиотеки следует паковать через LuaRocks. Это позволяет полуавтоматически отслеживать зависимости между модулями и в крайнем случае доустанавливать модули пользователям в локальном режиме.
Правила упаковки модулей:
- Модуль пакуется для определённой ветки Lua (например, 5.3). При необходимости, модуль можно собрать для разных веток. Упаковка для разных веток полностью независима.
- Именование модулей: lua%{версия_Lua}-module-имямод
- Модули устанавливаются в пути %_datadir/lua/%{версия_Lua} (noarch) и %_libdir/lua/%{версия_Lua} (arch)
- Модули собираются в RPM из rockspec при помощи утилиты lrimport. При желании возможна сборка без помощи этой утилиты.
- Зависимости между модулями выглядят так: luarocks%{версия_Lua}(имямод) <>= вермод
- Каждый пакет с модулем должен предоставлять: Provides: luarocks%{версия_Lua}(имямод) = %EVR
Пояснения:
- Двоичные (arch) модули собираются стандартно для последней версии. При возникновении необходимости в модуле для более старой версии интерпретатора, отдельный пакет порождается и собирается вручную, см. ниже
Правила упаковки программ, которые работают на /usr/bin/lua
Программы, имеющие в shebang #!/usr/bin/lua
или #!/usr/bin/env lua
, будут запускаться интерпретатором, на который ссылается /usr/bin/lua, т.е. на текущий момент lua-5.3
Отсюда следующие рекомендации:
- (как правило), если у программы есть привязка к версии интерпретатора, то это надо указать в shebang, например,
#!/usr/bin/lua5.1
или#!/usr/bin/lua5.3
- если у программы есть зависимость на модули lua, то необходимо их добавить в зависимости, учитывая версию интерпретатора (например,
luarocks5.3(luasocket)
илиluarocks5.1(luasocket)
)
Нерешенные проблемы
- lrimport не является полностью автоматизированным средством. Патчи приветствуются.
- Вследствие того, что в сборочную среду невозможно установить одновременно liblua5.3-devel и liblua5.1-devel, сборка двоичных модулей под два интерпретатора пока невозможна