Lua Policy: различия между версиями
(→Ссылки: добавлена ссылка на Lua and LuaRocks / Lua по-новому) |
(→Правила упаковки модулей Lua: черновик) |
||
Строка 34: | Строка 34: | ||
== Правила упаковки модулей Lua == | == Правила упаковки модулей Lua == | ||
Модули и Lua-библиотеки следует паковать через LuaRocks. Это позволяет полуавтоматически отслеживать зависимости между модулями и в крайнем случае доустанавливать модули пользователям в локальном режиме. | Модули и Lua-библиотеки следует паковать через LuaRocks. Это позволяет полуавтоматически отслеживать зависимости между модулями и в крайнем случае доустанавливать модули пользователям в локальном режиме. | ||
Как это выглядит: | |||
# Вся инфраструктура luarocks и модули собираются для последней версии Lua (на данный момент 5.3) | |||
# Именование модулей: ''lua-module-имямод'' | |||
# Модули устанавливаются в пути ''%_datadir/lua/5.3'' (noarch) и ''%_libdir/lua/5.3'' (arch) | |||
# Модули собираются в RPM из ''rockspec'' при помощи утилиты [http://git.altlinux.org/people/ildar/public/?p=lrimport.git lrimport]. | |||
# Зависимости между модулями выглядят так: ''luarocks(имямод) <>= вермод'' | |||
Пояснения: | |||
# Двоичные (arch) модули собираются стандартно для последней версии. При необходимости порождается и собирается пакет для более старой версии Lua (напр.5.1) вручную | |||
# Если модуль/Lua-библиотека хорошо совместима со старой версией Lua и является полностью noarch, то при помощи spec-макроса ''%{lua_modules_make_available_for_older_versions}'' модуль становится мульти-луа-пригодным | |||
== Основные термины == | == Основные термины == |
Версия от 12:06, 19 сентября 2017
Правила упаковки модулей и программ на языке Lua.
Список интерпретаторов Lua в ALTLinux
- Lua 5.1
- Lua 5.3
- LuaJIT 2.1
Общие соображения
Программы Lua могут исполняться в двух режимах:
- Программа, которая содержит в себе интерпретатор Lua (например, в виде библиотеки liblua.so.*), запускает Lua-часть средствами этого интерпретатора
- Скрипт Lua запускается с помощью интерпретатора, например /usr/bin/lua
Следовательно, всё-таки стоит отойти от практики явной линковки модулей с liblua.so и воспринимать эту библиотеку не как библиотеку, а как интерпретатор.
Модули и Lua-библиотеки следует паковать через LuaRocks. Это позволяет полуавтоматически отслеживать зависимости между модулями и в крайнем случае доустанавливать модули пользователям в локальном режиме.
О версиях Lua и их модулях
Давным-давно в ALTLinux была одна только 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-библиотеки следует паковать через LuaRocks. Это позволяет полуавтоматически отслеживать зависимости между модулями и в крайнем случае доустанавливать модули пользователям в локальном режиме.
Как это выглядит:
- Вся инфраструктура luarocks и модули собираются для последней версии Lua (на данный момент 5.3)
- Именование модулей: lua-module-имямод
- Модули устанавливаются в пути %_datadir/lua/5.3 (noarch) и %_libdir/lua/5.3 (arch)
- Модули собираются в RPM из rockspec при помощи утилиты lrimport.
- Зависимости между модулями выглядят так: luarocks(имямод) <>= вермод
Пояснения:
- Двоичные (arch) модули собираются стандартно для последней версии. При необходимости порождается и собирается пакет для более старой версии Lua (напр.5.1) вручную
- Если модуль/Lua-библиотека хорошо совместима со старой версией Lua и является полностью noarch, то при помощи spec-макроса %{lua_modules_make_available_for_older_versions} модуль становится мульти-луа-пригодным