Lua Policy: различия между версиями

Материал из ALT Linux Wiki
м (+rpm-macros-luajit)
 
(не показано 26 промежуточных версий 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=20.09.2017
|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 (например, в виде библиотеки liblua.so.*), запускает Lua-подпрограмму посредством этого интерпретатора
# Скрипт Lua запускается с помощью интерпретатора, например ''/usr/bin/lua''
# Скрипт Lua запускается с помощью программы-интерпретатора, ''/usr/bin/lua''


Следовательно, всё-таки стоит отойти от практики явной линковки модулей Lua с liblua.so и воспринимать эту библиотеку не как библиотеку, а как интерпретатор.
Следовательно, всё-таки стоит отойти от практики явной линковки модулей Lua с liblua.so и воспринимать эту библиотеку не как библиотеку, а как интерпретатор.


Модули и Lua-библиотеки следует паковать через ''LuaRocks''. Это позволяет полуавтоматически отслеживать зависимости между модулями и, в крайнем случае, доустанавливать модули пользователям в локальном режиме.
Модули Lua (как чистые-Lua, так и *.so) следует паковать через ''LuaRocks''. Это позволяет полуавтоматически отслеживать зависимости между модулями и, в крайнем случае, доустанавливать модули пользователям в локальном режиме.


=== О версиях Lua и их модулях ===
=== О версиях Lua и их модулях ===


Давным-давно в 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 интерпретатора (см. выше), реализующих две версии языка: 5.3 и 5.1 . Одним из критичных вопросов примем вопрос востребованности (интерпретаторов, модулей, ...).
Сейчас у нас [[#Список интерпретаторов 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 главной в вопросе поддержки модулей и их упаковки.
# Необходимо сохранить возможность упаковки модулей для определённых версий Lua, а также обеспечить максимальное облегчение сборки таких модулей
# Необходимо сохранить возможность упаковки модулей для определённых версий Lua, а также обеспечить максимальное облегчение сборки таких модулей
== Главная версия ==
Главной версии интерпретатора у нас не будет, версии работают независимо


== Правила упаковки модулей Lua ==
== Правила упаковки модулей Lua ==
Строка 41: Строка 46:
Модули и Lua-библиотеки следует паковать через LuaRocks. Это позволяет полуавтоматически отслеживать зависимости между модулями и в крайнем случае доустанавливать модули пользователям в локальном режиме.
Модули и Lua-библиотеки следует паковать через LuaRocks. Это позволяет полуавтоматически отслеживать зависимости между модулями и в крайнем случае доустанавливать модули пользователям в локальном режиме.


Как это выглядит:
Правила упаковки модулей:
# Вся инфраструктура luarocks и модули собираются для последней версии Lua (на данный момент 5.3)
# Модуль пакуется для определённой ветки Lua (например, 5.3). При необходимости, модуль можно собрать для разных веток. Упаковка для разных веток полностью независима.
# Именование модулей: ''lua-module-имямод''
# Именование модулей: ''lua%{версия_Lua}-module-имямод''
# Модули устанавливаются в пути ''%_datadir/lua/5.3'' (noarch) и ''%_libdir/lua/5.3'' (arch)
# Модули устанавливаются в пути ''%_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 ==
# Двоичные (arch) модули собираются стандартно для последней версии. При возникновении необходимости в модуле для более старой версии интерпретатора, отдельный пакет порождается и собирается вручную, см. раздел ниже
# Если модуль/Lua-библиотека хорошо совместима со старой версией Lua и является полностью noarch, то при помощи spec-макроса ''%{lua_modules_make_available_for_older_versions}'' модуль становится мульти-луа-пригодным, т.е. как для 5.3, так и для 5.1


== Правила упаковки модулей для старых версий языка ==
Программы, имеющие в shebang <code>#!/usr/bin/lua</code> или <code>#!/usr/bin/env lua</code>, будут запускаться интерпретатором, на который ссылается ''/usr/bin/lua'', т.е. на текущий момент ''lua-5.3''
Вследствие того, что в сборочную среду невозможно установить одновременно liblua5.3-devel и liblua5.1-devel, сборка двоичных модулей под два интерпретатора пока принципиально невозможна.


Поэтому при сборке этих модулей '''отдельно''', необходимо соблюдать следующие правила:
Отсюда следующие рекомендации:
# модули должны подчиняться всем правилам модулей Lua, описанным выше, учитывая корректировки, перечисленные ниже
* (как правило), если у программы есть привязка к версии интерпретатора, то это надо указать в shebang, например, <code>#!/usr/bin/lua5.1</code> или <code>#!/usr/bin/lua5.3</code>
# Именование модулей: lua%{версия_Lua}-module-имямод, например <code>lua5.1-module-luasocket</code>.
* если у программы есть зависимость на модули lua, то необходимо их добавить в зависимости, учитывая версию интерпретатора (например, <code>luarocks5.3(luasocket)</code> или <code>luarocks5.1(luasocket)</code>)
# в верхней части спека добавить версию Lua: <code>%define lua lua5.1</code>.
# Пакет должен предоставлять зависимость вида <code>luarocks%{версия_Lua}(luasocket)</code>, например <code>luarocks5.1(luasocket)</code>
# Пакет должен иметь зависимость вида <code>luarocks(luasocket) = %EVR</code>, т.е. зависеть от пакета для версии 5.3 и устанавливать его.
# <code>BuildPreReq: rpm-macros-lua >= 1.3 lib%lua-devel %lua</code>
# в %files <code>%exclude %luarocks_dbdir/%oname</code>
# зависимости от других модулей должны быть исправлены на модули для требуемой версии Lua


Если внести все эти правки в спек для основной версии модуля, должен получиться собираемый модуль для старой версии интерпретатора. Планируется написание скрипта, делающего это автоматически, который появится в репозитарии lrimport.
== Архитектуры LuaJIT ==


== Правила упаковки программ, которые работают на /usr/bin/lua ==
Во избежание поддержки списка <code>ExclusiveArch</code> вручную предлагается применять {{pkg|rpm-macros-luajit}}:
очень просты:
 
* имея в shebang <code>#!/usr/bin/lua</code> или <code>#!/usr/bin/env lua</code>, программа будет запускаться имеющимся интерпретатором, как то lua5.3 или lua5.1 (или luajit), а зависимость на /usr/bin/lua будет вычисляться автоматически средствами ALT Linux
BuildRequires(pre): rpm-macros-luajit
* если у программы есть привязка к версии интерпретатора, то это надо указать в shebang, например, <code>#!/usr/bin/lua5.1</code> или <code>#!/usr/bin/lua5.3</code>
* если у программы есть зависимость на модули lua, то необходимо их добавить в зависимости, учитывая версию интерпретатора (например, <code>luarocks(luasocket)</code> или <code>luarocks5.1(luasocket)</code>)
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 под два интерпретатора пока невозможна


== Ссылки ==
== Ссылки ==

Текущая версия от 12:51, 5 июля 2021

Stub.png
Черновик политики Sisyphus
Автор(ы) — ildar@
Обсуждение в devel@
Обсуждается с 06.10.2017


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

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

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

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

  • фактически транслятор языка находится в библиотеке и предоставляется пакетами liblua5.x и libluajit
  • программа /usr/bin/lua из пакета lua5.x является только средством для запуска скриптов Lua и чистых-Lua-программ (как тот же LuaRocks).
  • каждая из веток (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 выкинули. Сейчас у нас 3 интерпретатора, реализующих две версии языка: 5.3 и 5.1 . Одним из критичных вопросов примем вопрос востребованности (интерпретаторов, модулей, ...).

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

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

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

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

Модули и Lua-библиотеки следует паковать через LuaRocks. Это позволяет полуавтоматически отслеживать зависимости между модулями и в крайнем случае доустанавливать модули пользователям в локальном режиме.

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

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

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

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

Ссылки