Lua Policy

Материал из ALT Linux Wiki
(разн.) ← Предыдущая версия | Текущая версия (разн.) | Следующая версия → (разн.)
Stub.png
Черновик политики Sisyphus
Автор(ы) — ildar@
Обсуждение в devel@
Обсуждается с 06.10.2017


Правила упаковки модулей и программ на языке Lua.

Список интерпретаторов Lua в ALT Linux

  1. Lua 5.1
  2. Lua 5.3
  3. Lua 5.4
  4. LuaJIT 2.1 (совместим с Lua 5.1)

Для ясности стоит также упомянуть, что:

  • фактически транслятор языка находится в библиотеке и предоставляется пакетами liblua5.x и libluajit
  • программы /usr/bin/lua5.x из пакета lua5.x является только средством для запуска скриптов Lua и чистых-Lua-программ (как тот же LuaRocks).
  • каждая из веток (5.4, 5.3 и 5.1) у нас независимы, в том числе интерпретатор и дерево модулей. Ситуации, когда зависимости пакетов пересекают границы веток, считаются ошибкой.

Общие соображения

Программы Lua могут исполняться в двух режимах:

  1. Какая-то программа, которая содержит в себе интерпретатор Lua (например, в виде библиотеки liblua.so.*), запускает Lua-подпрограмму посредством этого интерпретатора
  2. Скрипт 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 выкинули. Сейчас у нас 4 интерпретатора, реализующих три версии языка: 5.4, 5.3 и 5.1 . Одним из критичных вопросов примем вопрос востребованности (интерпретаторов, модулей, ...).

  1. Понятно, что каждый из интерпретаторов востребован теми пакетами, которые от него зависят; как какой-нибудь love работает на libluajit.so, поэтому в его зависимостях это прописано явно;
  2. Для модулей у нас есть зависимости их друг от друга и от версии Lua. Вопрос востребованности (т.е. вопрос: для какой версии Lua нужны модули?) открывается очень простым. На самом деле в 95% случаев подходит Lua >= 5.1. Это позволяет принять версию 5.4 предпочтительной в вопросе поддержки модулей и их упаковки, если нет других условий (например, если определённой программе нужна именно определённая версия Lua);
  3. Необходимо сохранить возможность упаковки модулей для определённых версий Lua, а также обеспечить максимальное облегчение сборки таких модулей

Главная версия

Главной версии интерпретатора у нас не будет, версии работают независимо

Правила упаковки модулей Lua

Модули и Lua-библиотеки удобно, но не обязательно паковать через LuaRocks. С 2024-го года работает механизм автоматического поиска зависимостей.

Правила упаковки модулей:

  1. Модуль пакуется для определённой ветки Lua (например, 5.3). При необходимости, модуль можно собрать для разных веток. Упаковка для разных веток априори полностью независима, хотя модули noarch можно собирать для разных версий Lua из одного SRPM.
  2. Именование модулей: lua%{версия_Lua}-module-имямод
  3. Модули устанавливаются в пути %_datadir/lua/%{версия_Lua} (noarch) и %_libdir/lua/%{версия_Lua} (arch)
  4. Модули можно собирать в RPM из rockspec при помощи утилиты lrimport. При желании возможна сборка без помощи этой утилиты.
  5. Зависимости между модулями выглядят так: lua%{версия_Lua}(имямод) <>= вермод. Зависимости выставляются в RPM автоматически при условии установленного пакета rpm-build-lua. Поэтому наличие в сборочном окружении пакета rpm-build-lua обязательно.
  6. Каждый пакет, собранный при помощи LuaRocks, должен предоставлять также: Provides: luarocks%{версия_Lua}(имямод) = %EVR

Правила упаковки программ, которые работают на /usr/bin/lua

Программы, имеющие в shebang #!/usr/bin/lua или #!/usr/bin/env lua, будут запускаться интерпретатором, на который ссылается /usr/bin/lua, т.е. на текущий момент lua-5.4

Отсюда следующие рекомендации:

  • (как правило), если у программы есть привязка к версии интерпретатора, то это надо указать в shebang, например, #!/usr/bin/lua5.1 или #!/usr/bin/lua5.3
  • если у программы есть зависимость на модули lua, то необходимо их добавить в зависимости, учитывая версию интерпретатора (например, luarocks5.3(luasocket) или luarocks5.1(luasocket))

Архитектуры LuaJIT

Во избежание поддержки списка ExclusiveArch вручную предлагается применять rpm-macros-luajit: 

BuildRequires(pre): rpm-macros-luajit

ExclusiveArch: %luajit_arches

Нерешенные проблемы

  1. lrimport не является полностью автоматизированным средством. Патчи приветствуются.
  2. Вследствие того, что в сборочную среду невозможно установить одновременно liblua5.3-devel и liblua5.1-devel, сборка двоичных модулей из одного SRPM под два интерпретатора пока невозможна

Ссылки