Lua Policy: различия между версиями
(→Правила упаковки модулей Lua: актуализировано в связи с определением Главной версии) |
м (+rpm-macros-luajit) |
||
(не показаны 22 промежуточные версии 1 участника) | |||
Строка 1: | Строка 1: | ||
{{DraftPolicy | {{DraftPolicy | ||
|responsible=ildar@ | |responsible=ildar@ | ||
|discussion_link=... | |discussion_link=https://lists.altlinux.org/pipermail/devel/2017-October/thread.html#203116 | ||
|discussion_since= | |discussion_since=06.10.2017 | ||
}} | }} | ||
Строка 18: | Строка 18: | ||
* фактически транслятор языка находится в библиотеке и предоставляется пакетами ''liblua5.x'' и ''libluajit'' | * фактически транслятор языка находится в библиотеке и предоставляется пакетами ''liblua5.x'' и ''libluajit'' | ||
* программа ''/usr/bin/lua'' из пакета ''lua5.x'' является только средством для запуска скриптов Lua и чистых-Lua-программ (как тот же LuaRocks). | * программа ''/usr/bin/lua'' из пакета ''lua5.x'' является только средством для запуска скриптов Lua и чистых-Lua-программ (как тот же LuaRocks). | ||
* каждая из веток (5.3 и 5.1) у нас независимы от интерпретатора до дерева модулей. Ситуации, когда зависимости пакетов пересекают границы веток, считаются ошибкой. | |||
== Общие соображения == | == Общие соображения == | ||
Программы Lua могут исполняться в двух режимах: | Программы Lua могут исполняться в двух режимах: | ||
# | # Какая-то программа, которая содержит в себе интерпретатор Lua (например, в виде библиотеки liblua.so.*), запускает Lua-подпрограмму посредством этого интерпретатора | ||
# Скрипт Lua запускается с помощью интерпретатора, | # Скрипт Lua запускается с помощью программы-интерпретатора, ''/usr/bin/lua'' | ||
Следовательно, всё-таки стоит отойти от практики явной линковки модулей Lua с liblua.so и воспринимать эту библиотеку не как библиотеку, а как интерпретатор. | Следовательно, всё-таки стоит отойти от практики явной линковки модулей Lua с liblua.so и воспринимать эту библиотеку не как библиотеку, а как интерпретатор. | ||
Строка 32: | Строка 33: | ||
Давным-давно в ALT Linux была одна только Lua 5.0 . С тех пор у нас стандартными путями для модулей были ''%_datadir/lua5'' и ''%_libdir/lua5'' . Потом вышла Lua 5.1 и версию 5.0 выкинули. | Давным-давно в ALT Linux была одна только Lua 5.0 . С тех пор у нас стандартными путями для модулей были ''%_datadir/lua5'' и ''%_libdir/lua5'' . Потом вышла Lua 5.1 и версию 5.0 выкинули. | ||
Сейчас у нас 3 интерпретатора | Сейчас у нас [[#Список интерпретаторов Lua в ALT Linux|3 интерпретатора]], реализующих две версии языка: 5.3 и 5.1 . Одним из критичных вопросов примем вопрос востребованности (интерпретаторов, модулей, ...). | ||
# Понятно, что каждый из интерпретаторов востребован теми пакетами, которые от них зависят, как какой-нибудь ''love'' работает на ''libluajit.so'', поэтому в его зависимостях это прописано явно | # Понятно, что каждый из интерпретаторов востребован теми пакетами, которые от них зависят, как какой-нибудь ''love'' работает на ''libluajit.so'', поэтому в его зависимостях это прописано явно | ||
# Для модулей у нас есть зависимости их друг от друга и от версии Lua (пример?). Вопрос востребованности (т.е. вопрос: для какой версии Lua нужны модули?) открывается очень простым. На самом деле в 95% случаев подходит ''Lua >= 5.1''. Это позволяет принять версию 5.3 главной в вопросе поддержки модулей и их упаковки. | # Для модулей у нас есть зависимости их друг от друга и от версии Lua (пример?). Вопрос востребованности (т.е. вопрос: для какой версии Lua нужны модули?) открывается очень простым. На самом деле в 95% случаев подходит ''Lua >= 5.1''. Это позволяет принять версию 5.3 главной в вопросе поддержки модулей и их упаковки. | ||
Строка 39: | Строка 40: | ||
== Главная версия == | == Главная версия == | ||
Главной | Главной версии интерпретатора у нас не будет, версии работают независимо | ||
== Правила упаковки модулей Lua == | == Правила упаковки модулей Lua == | ||
Строка 48: | Строка 46: | ||
Модули и Lua-библиотеки следует паковать через LuaRocks. Это позволяет полуавтоматически отслеживать зависимости между модулями и в крайнем случае доустанавливать модули пользователям в локальном режиме. | Модули и Lua-библиотеки следует паковать через LuaRocks. Это позволяет полуавтоматически отслеживать зависимости между модулями и в крайнем случае доустанавливать модули пользователям в локальном режиме. | ||
Правила упаковки модулей | Правила упаковки модулей: | ||
# | # Модуль пакуется для определённой ветки Lua (например, 5.3). При необходимости, модуль можно собрать для разных веток. Упаковка для разных веток полностью независима. | ||
# Именование модулей: ''lua-module-имямод'' | # Именование модулей: ''lua%{версия_Lua}-module-имямод'' | ||
# Модули устанавливаются в пути ''%_datadir/lua/ | # Модули устанавливаются в пути ''%_datadir/lua/%{версия_Lua}'' (noarch) и ''%_libdir/lua/%{версия_Lua}'' (arch) | ||
# Модули собираются в RPM из ''rockspec'' при помощи утилиты [http://git.altlinux.org/people/ildar/public/?p=lrimport.git lrimport]. | # Модули собираются в RPM из ''rockspec'' при помощи утилиты [http://git.altlinux.org/people/ildar/public/?p=lrimport.git lrimport]. При желании возможна сборка без помощи этой утилиты. | ||
# Зависимости между модулями выглядят так: ''luarocks(имямод) <>= вермод'' | # Зависимости между модулями выглядят так: ''luarocks%{версия_Lua}(имямод) <>= вермод'' | ||
# Каждый пакет с модулем должен предоставлять: ''Provides: luarocks%{версия_Lua}(имямод) = %EVR'' | |||
== Правила упаковки программ, которые работают на /usr/bin/lua == | |||
Программы, имеющие в shebang <code>#!/usr/bin/lua</code> или <code>#!/usr/bin/env lua</code>, будут запускаться интерпретатором, на который ссылается ''/usr/bin/lua'', т.е. на текущий момент ''lua-5.3'' | |||
Отсюда следующие рекомендации: | |||
* (как правило), если у программы есть привязка к версии интерпретатора, то это надо указать в shebang, например, <code>#!/usr/bin/lua5.1</code> или <code>#!/usr/bin/lua5.3</code> | |||
* если у программы есть зависимость на модули lua, то необходимо их добавить в зависимости, учитывая версию интерпретатора (например, <code>luarocks5.3(luasocket)</code> или <code>luarocks5.1(luasocket)</code>) | |||
== Архитектуры LuaJIT == | |||
Во избежание поддержки списка <code>ExclusiveArch</code> вручную предлагается применять {{pkg|rpm-macros-luajit}}: | |||
BuildRequires(pre): rpm-macros-luajit | |||
ExclusiveArch: %luajit_arches | |||
== Нерешенные проблемы == | == Нерешенные проблемы == | ||
# [http://git.altlinux.org/people/ildar/public/?p=lrimport.git lrimport] не является полностью автоматизированным средством. Патчи приветствуются. | # [http://git.altlinux.org/people/ildar/public/?p=lrimport.git lrimport] не является полностью автоматизированным средством. Патчи приветствуются. | ||
# Вследствие того, что в сборочную среду невозможно установить одновременно liblua5.3-devel и liblua5.1-devel, сборка двоичных модулей под два интерпретатора пока невозможна | # Вследствие того, что в сборочную среду невозможно установить одновременно liblua5.3-devel и liblua5.1-devel, сборка двоичных модулей из одного SRPM под два интерпретатора пока невозможна | ||
== Ссылки == | == Ссылки == |
Текущая версия от 09:51, 5 июля 2021
Правила упаковки модулей и программ на языке 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
Правила упаковки программ, которые работают на /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)
)
Архитектуры LuaJIT
Во избежание поддержки списка ExclusiveArch
вручную предлагается применять rpm-macros-luajit:
BuildRequires(pre): rpm-macros-luajit ExclusiveArch: %luajit_arches
Нерешенные проблемы
- lrimport не является полностью автоматизированным средством. Патчи приветствуются.
- Вследствие того, что в сборочную среду невозможно установить одновременно liblua5.3-devel и liblua5.1-devel, сборка двоичных модулей из одного SRPM под два интерпретатора пока невозможна