[devel] судьба одного пакета (rpm-build-lua)

[devel] судьба одного пакета (rpm-build-lua)

[Ildar Mulyukov]

Коллеги,

не знаю точно, к кому обратиться, поэтому пишу сюда. Не ради флейма.
Отвечать можно и приватно. Спасибо.

Пакет rpm-build-lua был изначально создан Владимиром Селезнёвым и был
в ACL закрыт для всех, кроме автора. Владимир отстранился от ALT, так
что пакет остался без доступа.

Я написал приватно, и парни из Базальт почему-то отдали пакет Данилу
(Daniel Zagaynov). Я, честно говоря, не понял, из каких соображений.

Теперь мои версии пакета ждут его апрува. Последний уже больше трёх месяцев.

Прошу кого-нибудь принять какие-нибудь меры. В таком режиме
контрибьютить (в свободное от работы время) совсем, мягко говоря,
некомфортно. И совершенно непонятно, где я лично растратил свой кредит
доверия со стороны сообщества ALT Linux Team.

Спасибо за внимание.

P.S. кому интересно, вот история пакета:
https://git.altlinux.org/gears/r/rpm-build-lua.git?p=rpm-build-lua.git;a=log
-- 
Ildar Mulyukov,
(ΙΧΘΥΣ) child of God

email: ildar.mulyukov@gmail.com
matrix: @ildar:matrix.org
blog: http://johan-notes.blogspot.com/

Re: [devel] судьба одного пакета (rpm-build-lua)

[Anton Farygin]

Ильдар,

On 7/28/25 17:44, Ildar Mulyukov wrote:
> Коллеги,
>
> не знаю точно, к кому обратиться, поэтому пишу сюда. Не ради флейма.
> Отвечать можно и приватно. Спасибо.
>
> Пакет rpm-build-lua был изначально создан Владимиром Селезнёвым и был
> в ACL закрыт для всех, кроме автора. Владимир отстранился от ALT, так
> что пакет остался без доступа.
>
> Я написал приватно, и парни из Базальт почему-то отдали пакет Данилу
> (Daniel Zagaynov). Я, честно говоря, не понял, из каких соображений.
>
> Теперь мои версии пакета ждут его апрува. Последний уже больше трёх месяцев.
>
> Прошу кого-нибудь принять какие-нибудь меры. В таком режиме
> контрибьютить (в свободное от работы время) совсем, мягко говоря,
> некомфортно. И совершенно непонятно, где я лично растратил свой кредит
> доверия со стороны сообщества ALT Linux Team.
>
> Спасибо за внимание.
>
> P.S. кому интересно, вот история пакета:
> https://git.altlinux.org/gears/r/rpm-build-lua.git?p=rpm-build-lua.git;a=log

https://packages.altlinux.org/ru/sisyphus/srpms/rpm-build-lua/tasks/pkg_index/?task_repo=sisyphus

Я кстати не вижу вообще никаких изменений в этом пакете от Daniel и нет 
даже попыток это сделать.

Re: [devel] судьба одного пакета (rpm-build-lua)

[Fr. Br. George]

Ильдар, приветствую!

On Mon, Jul 28, 2025 at 07:44:09PM +0500, Ildar Mulyukov wrote:
> Пакет rpm-build-lua был изначально создан Владимиром Селезнёвым и был
> в ACL закрыт для всех, кроме автора. Владимир отстранился от ALT, так
> что пакет остался без доступа.
> 
> Теперь мои версии пакета ждут его апрува. Последний уже больше трёх месяцев.
Правильно ли я понимаю, что разговор идёт не о той ссылке, которую вы
привели в письме (это как раз _успешная_ история пакета за вашим
авторством), а вот об этом:
https://git.altlinux.org/tasks/381946/gears/300/git?p=git;a=commitdiff;h=b862def6

Под это дело в апреле был основательно переписан _черновик_ ALT Lua
Policy — но обсуждения особого не последовало.

> Прошу кого-нибудь принять какие-нибудь меры.
Мне кажется, «меры» принимать ещё рано — лучше всё-таки поднапрячься
и бОльшим количеством читателей почитать этот вот коммит, раз уж он
реализует новый вариант полиси. И вчитаться в само полиси — возможно,
проблема там.

Я попробовал пересобрать с этим rpm-build-lua пакет —
теперь provides `lua5.№(…)` дублируется как `luarocks5.№(…)`

В проекте полиси сказано:
> Разница между этими зависимостями существенная:
> lua5.x(MOD) — это название модуля Lua, который можно использовать из программы Lua: `require 'MOD'`
> luarocks5.x(ROCK) — это название пакета LuaRocks, который может содержать несколько модулей
(увы, это ответ на вопрос «как?», а не «зачем?»)

Правильно ли я понимаю, что фактическое удвоение полей Provides в пакете служит
одной-единственной цели: возможности в дальнейшем _вручную_ указывать зависимость на
«пакет LuaRocks»? Автоматического поиска зависимостей на пакет LuaRocks
у нас нет…

Но ведь если поиск зависимостей на «модуль Lua» работает:
https://git.altlinux.org/gears/r/rpm-build-lua.git?p=rpm-build-lua.git;a=blob;f=lua.req;h=c608b219
то в таком указании нет необходимости: нужный RPM-пакет подтянется по
provides-ам на его модуль.

Кстати, в Python есть так же проблема — несоответствие самоименования
пакетов (как они представляются в pip install) и имён, которые они
впоследствии провайдят (например, с заменой минусов на подчёркивание).

Вроде как provides-ы надёжнее самоименования…


-- 
	Fr. Br. George

Re: [devel] судьба одного пакета (rpm-build-lua)

[Ildar Mulyukov]

Здравствуйте, Георгий!

как говорят "спасибо, что спросили"! :-)

On Mon, Jul 28, 2025 at 10:46 PM Fr. Br. George <george@altlinux.org> wrote:
> On Mon, Jul 28, 2025 at 07:44:09PM +0500, Ildar Mulyukov wrote:
> > Пакет rpm-build-lua был изначально создан Владимиром Селезнёвым и был
> > в ACL закрыт для всех, кроме автора. Владимир отстранился от ALT, так
> > что пакет остался без доступа.
> >
> > Теперь мои версии пакета ждут его апрува. Последний уже больше трёх месяцев.

> Правильно ли я понимаю, что разговор идёт не о той ссылке, которую вы
> привели в письме (это как раз _успешная_ история пакета за вашим
> авторством), а вот об этом:
> https://git.altlinux.org/tasks/381946/gears/300/git?p=git;a=commitdiff;h=b862def6

И да, и нет. Вопрос о том, нужно ли это изменение или нет, уже
потускнел за три месяца. Сюда я написал уже с другим вопросом: как так
получается, что "ни вперёд, ни назад" и это, с позволения сказать, с
молчаливого одобрения не одного сотрудника Базальт.

Впрочем, таск, который не пропускает Данила — да, это #381946.

> Под это дело в апреле был основательно переписан _черновик_ ALT Lua
> Policy — но обсуждения особого не последовало.

Ну, похоже, что просто не с кем обсуждать. Впрочем, я на это не жалуюсь.

> > Прошу кого-нибудь принять какие-нибудь меры.
> Мне кажется, «меры» принимать ещё рано — лучше всё-таки поднапрячься
> и бОльшим количеством читателей почитать этот вот коммит, раз уж он
> реализует новый вариант полиси. И вчитаться в само полиси — возможно,
> проблема там.

Я просто даже не знаю, как другими словами описать, что модуль Lua и
пакет LuaRocks — это просто разные вещи.

> Я попробовал пересобрать с этим rpm-build-lua пакет —
> теперь provides `lua5.№(…)` дублируется как `luarocks5.№(…)`

совпадение. См. ниже.

> В проекте полиси сказано:
> > Разница между этими зависимостями существенная:
> > lua5.x(MOD) — это название модуля Lua, который можно использовать из программы Lua: `require 'MOD'`
> > luarocks5.x(ROCK) — это название пакета LuaRocks, который может содержать несколько модулей
> (увы, это ответ на вопрос «как?», а не «зачем?»)

Пакет LuaRocks может содержать (и часто содержит) множество модулей
Lua внутри себя. В каждом современном языке есть прямые аналогии:
crate, package, go mod, pypi, модули OCaml и т.п.

> Правильно ли я понимаю, что фактическое удвоение полей Provides в пакете служит
> одной-единственной цели: возможности в дальнейшем _вручную_ указывать зависимость на
> «пакет LuaRocks»? Автоматического поиска зависимостей на пакет LuaRocks
> у нас нет…

Есть полуавтоматический поиск в утилите lrimport.

Зависимости на LuaRocks нужны самим пакетам LuaRocks, т.к. именно
такие зависимости используются в этой экосистеме (а не зависимости на
модули Lua).

> Но ведь если поиск зависимостей на «модуль Lua» работает:
> https://git.altlinux.org/gears/r/rpm-build-lua.git?p=rpm-build-lua.git;a=blob;f=lua.req;h=c608b219
> то в таком указании нет необходимости: нужный RPM-пакет подтянется по
> provides-ам на его модуль.

см. выше: в самих пакетах LuaRocks используются зависимости на пакеты LR.

> Кстати, в Python есть так же проблема — несоответствие самоименования
> пакетов (как они представляются в pip install) и имён, которые они
> впоследствии провайдят (например, с заменой минусов на подчёркивание).
>
> Вроде как provides-ы надёжнее самоименования…

Я не знаток этой проблемы в Питоне. В Lua это всё-таки полностью
независимые понятия и ортогональные пространства имён.

С уважением, Ильдар
-- 
Ildar Mulyukov,
(ΙΧΘΥΣ) child of God

email: ildar.mulyukov@gmail.com
matrix: @ildar:matrix.org
blog: http://johan-notes.blogspot.com/

Re: [devel] судьба одного пакета (rpm-build-lua)

[Anton Farygin]

On 7/28/25 22:53, Ildar Mulyukov wrote:
> Правильно ли я понимаю, что разговор идёт не о той ссылке, которую вы
> привели в письме (это как раз_успешная_ история пакета за вашим
> авторством), а вот об этом:
> https://git.altlinux.org/tasks/381946/gears/300/git?p=git;a=commitdiff;h=b862def6

вообще конечно такое удобнее смотреть и комментировать в каком-то git а 
не в сборочном задании.

Если я правильно понял commit то он в параллель к обычным и привычным 
нам provides добавляет provides luarocks с целью (наверное) в дальнейшем 
задействовать LuaRocks для построения межпакетных зависимостей rpm пакетов.

Но предложенная реализация не добавляет использования этих Provides, а 
только добавляет их наличие.


Сейчас действительно есть такие зависимости

https://packages.altlinux.org/ru/sisyphus/deps/?q=luarocks5.1

и прописываются они руками:

https://packages.altlinux.org/ru/sisyphus/srpms/lua5.1-module-http/specfiles/2749524596270163604#line-27

Честно не совсем понятно чем оно лучше/хуже, но пакет с модулем lua 
провайдит сразу три сущности:
https://packages.altlinux.org/ru/sisyphus/binary/lua5.1-module-basexx/noarch/depends/2514392821593640663

А именно:

     lua5-basexx = 0.4.1
     lua5.1-module-basexx = 0.4.1-alt2:sisyphus+248806.100.1.1
     luarocks5.1(basexx) = 0.4.1-alt2

зачем действительно дублировать сущности пока неясно, наверное есть план 
отказаться от чего-то одного в пользу чего-то другого.

И если посмотреть на спекфайл:

# Original package name basexx
%define oname basexx
%define oversion 0.4.1-1
%define rockspec basexx-0.4.1-1.rockspec
Name: lua%target_lua_version-module-%oname
Version: 0.4.1
Release: alt2
Summary: A base2, base16, base32, base64 and base85 library for Lua
License: MIT
Group: Development/Other
Url: https://github.com/aiq/basexx
BuildArch: noarch
Provides: luarocks%target_lua_version(%oname) = %EVR

%if "%target_lua_version" == "5.3"
Obsoletes: lua-module-%oname < %EVR
Provides: lua-module-%oname = %version
%else
Obsoletes: lua5-%oname < %EVR
Provides: lua5-%oname = %version
%endif

Source: https://github.com/aiq/basexx/archive/v0.4.1.tar.gz
Source1: https://luarocks.org/manifests/luarocks/basexx-0.4.1-1.rockspec

BuildRequires(pre): rpm-macros-lua >= 1.4
# Automatically added by buildreq on ...
BuildRequires: liblua%target_lua_version-devel 
lua%target_lua_version-luarocks

То в нём видно что провайд на luarocks тоже идёт вручную (что собственно 
и чинит данное исправление).

Но я бы тогда предложил убрать старые provides и заменить их полностью 
на luarocks. Это вообще возможно ?

И мне кажется что этот диалог без ментейнера lua невозможен, а именно на 
нём висит ACL rpm-build-lua

https://packages.altlinux.org/ru/sisyphus/srpms/lua5.4/

Re: [devel] судьба одного пакета (rpm-build-lua)

[Ildar Mulyukov]

Немного мат.части.

Связанные с Lua пакеты у нас делятся на 2 категории: собирающиеся
традиционным способом (configure-make-make install) и из пакетов
LuaRocks. Сразу отмечу, что когда модулей становится много, то второй
подход уже сильно облегчает жизнь мэйнтейнеру *)

Напомню, что пространство имён пакетов LuaRocks — это отдельное,
независимое от пространства имён модулей Lua множество.

On Tue, Jul 29, 2025 at 5:05 PM Anton Farygin <rider@basealt.ru> wrote:
> On 7/28/25 22:53, Ildar Mulyukov wrote:
> > Правильно ли я понимаю, что разговор идёт не о той ссылке, которую вы
> > привели в письме (это как раз_успешная_ история пакета за вашим
> > авторством), а вот об этом:
> > https://git.altlinux.org/tasks/381946/gears/300/git?p=git;a=commitdiff;h=b862def6
>
> вообще конечно такое удобнее смотреть и комментировать в каком-то git а
> не в сборочном задании.
>
> Если я правильно понял commit то он в параллель к обычным и привычным
> нам provides добавляет provides luarocks с целью (наверное) в дальнейшем
> задействовать LuaRocks для построения межпакетных зависимостей rpm пакетов.

Дополнительная деталь: эти зависимости конечному пользователю не
нужны. Они нужны самим опакеченным LuaRocks-ам, чтобы соблюсти между
ними зависимости времени сборки (не исполнения). Эти зависимости
возникают внутри логики LuaRocks.

> Но предложенная реализация не добавляет использования этих Provides, а
> только добавляет их наличие.

Об этом я писал в позапрошлом письме про полуавтоматические зависимости.

> Сейчас действительно есть такие зависимости
> https://packages.altlinux.org/ru/sisyphus/deps/?q=luarocks5.1
> и прописываются они руками:
> https://packages.altlinux.org/ru/sisyphus/srpms/lua5.1-module-http/specfiles/2749524596270163604#line-27
>
> Честно не совсем понятно чем оно лучше/хуже, но пакет с модулем lua
> провайдит сразу три сущности:
> https://packages.altlinux.org/ru/sisyphus/binary/lua5.1-module-basexx/noarch/depends/2514392821593640663
>
> А именно:
>      lua5-basexx = 0.4.1

Это legacy-зависимость для тех, кто ищет содержимое по этому имени
(если раньше пакет собирался configure-make-make install). Такая
зависимость есть/нужна далеко не у всех пакетов.

>      lua5.1-module-basexx = 0.4.1-alt2:sisyphus+248806.100.1.1
>      luarocks5.1(basexx) = 0.4.1-alt2
>
> зачем действительно дублировать сущности пока неясно, наверное есть план
> отказаться от чего-то одного в пользу чего-то другого.

Действительно, технически можно было бы отказаться от искусственной
зависимости (luarocks5.1(basexx)) в пользу стандартной пакетной
(lua5.1-module-basexx). Но тут сразу видно аккуратно разложенные
грабли: ошибка в имени пакета, пакет с нужным именем, но без
luarocks-содержимого и т.п.

Хорошо бы понять что мы экономим и зачем.

> И если посмотреть на спекфайл:
> ...
> То в нём видно что провайд на luarocks тоже идёт вручную (что собственно
> и чинит данное исправление).
>
> Но я бы тогда предложил убрать старые provides и заменить их полностью
> на luarocks. Это вообще возможно ?

Естественно, ручной Provides должен быть удалён, это пункт 6 в
https://www.altlinux.org/Lua_Policy#Правила_упаковки_модулей_Lua

> И мне кажется что этот диалог без ментейнера lua невозможен, а именно на
> нём висит ACL rpm-build-lua

:-\

*) https://altlinux.space/ildar/rocks
-- 
Ildar Mulyukov,
(ΙΧΘΥΣ) child of God

email: ildar.mulyukov@gmail.com
matrix: @ildar:matrix.org
blog: http://johan-notes.blogspot.com/

Re: [devel] судьба одного пакета (rpm-build-lua)

[Anton Farygin]

On 7/29/25 18:28, Ildar Mulyukov wrote:
> Дополнительная деталь: эти зависимости конечному пользователю не
> нужны. Они нужны самим опакеченным LuaRocks-ам, чтобы соблюсти между
> ними зависимости времени сборки (не исполнения). Эти зависимости
> возникают внутри логики LuaRocks.

А как разрешается проблема того, что часть нужных пакетов собирается не 
через LuaRocks, но при этом необходимо что бы LuaRocks находил нужные 
зависимости ?

Re: [devel] судьба одного пакета (rpm-build-lua)

[Ildar Mulyukov]

Добрый день,

On Wed, Jul 30, 2025 at 11:43 AM Anton Farygin <rider@basealt.ru> wrote:
> On 7/29/25 18:28, Ildar Mulyukov wrote:
> > Дополнительная деталь: эти зависимости конечному пользователю не
> > нужны. Они нужны самим опакеченным LuaRocks-ам, чтобы соблюсти между
> > ними зависимости времени сборки (не исполнения). Эти зависимости
> > возникают внутри логики LuaRocks.
>
> А как разрешается проблема того, что часть нужных пакетов собирается не
> через LuaRocks, но при этом необходимо что бы LuaRocks находил нужные
> зависимости ?

TL;DR; Боюсь, только пересборкой новым спеком.

Подробнее: Пусть пакет A имеет BuildRequires: luarocks5.3(B), но B
собран `configure-make`. Тогда придётся выкинуть спек пакета B,
создать новый (утилитой lrimport или вручную) и пересобрать
lua5.1-module-B посредством LuaRocks.
-- 
Ildar Mulyukov,
(ΙΧΘΥΣ) child of God

email: ildar.mulyukov@gmail.com
matrix: @ildar:matrix.org
blog: http://johan-notes.blogspot.com/

Re: [devel] судьба одного пакета (rpm-build-lua)

[Anton Farygin]

On 7/30/25 11:08, Ildar Mulyukov wrote:
> Добрый день,
>
> On Wed, Jul 30, 2025 at 11:43 AM Anton Farygin <rider@basealt.ru> wrote:
>> On 7/29/25 18:28, Ildar Mulyukov wrote:
>>> Дополнительная деталь: эти зависимости конечному пользователю не
>>> нужны. Они нужны самим опакеченным LuaRocks-ам, чтобы соблюсти между
>>> ними зависимости времени сборки (не исполнения). Эти зависимости
>>> возникают внутри логики LuaRocks.
>> А как разрешается проблема того, что часть нужных пакетов собирается не
>> через LuaRocks, но при этом необходимо что бы LuaRocks находил нужные
>> зависимости ?
> TL;DR; Боюсь, только пересборкой новым спеком.
>
> Подробнее: Пусть пакет A имеет BuildRequires: luarocks5.3(B), но B
> собран `configure-make`. Тогда придётся выкинуть спек пакета B,
> создать новый (утилитой lrimport или вручную) и пересобрать
> lua5.1-module-B посредством LuaRocks.

т.е. - все пакеты lua надо перевести на luarocks, а старые provides 
убрать и всё будет хорошо ?

А может быть генерить не luarocks провайды, а просто lua5.x(module) ?

Re: [devel] судьба одного пакета (rpm-build-lua)

[Ildar Mulyukov]

Антон,

On Wed, Jul 30, 2025 at 2:11 PM Anton Farygin <rider@basealt.ru> wrote:
> т.е. - все пакеты lua надо перевести на luarocks, а старые provides
> убрать и всё будет хорошо ?

по необходимости эту работу проделываем. Если модуль висит сам по себе
и никому не нужен --- можно и не трогать.

Obsoletes/Provides для старых пакетов нужны тем, у кого они уже
установлены, для гладкого обновления.

> А может быть генерить не luarocks провайды, а просто lua5.x(module) ?

первые — это зависимости LuaRocks-пакетов, а вторые — Lua-модулей.
Круг замкнулся, разницу между ними я уже объяснил. Это просто разные
сущности.
-- 
Ildar Mulyukov,
(ΙΧΘΥΣ) child of God

email: ildar.mulyukov@gmail.com
matrix: @ildar:matrix.org
blog: http://johan-notes.blogspot.com/

Re: [devel] судьба одного пакета (rpm-build-lua)

[Daniel]

[-- Attachment #1: Type: text/plain, Size: 1113 bytes --]

    Hello,

    Ильдар, как я понимаю сейчас то, что Вы хотите сделать, это
    двигаться в сторону автоматизации сопровождения пакетов из
    luarocks. Тогда BR определяются из исходников с некоторой
    степенью автоматизации и Вам действительно нужны ровно эти
    provides, так как имен пакетов недостаточно (в силу
    возможного ложноположительного provides-а, например, из-за
    коллизии в именах пакетов). Если я Вас неправильно понял, то,
    пожалуйста, исправьте меня. Если все же правильно, то опишите,
    пожалуйста, в commit message, в чем цель этих provides, и мне
    этого будет достаточно, чтобы пропустить Ваше задание.


-- 
kotopesutility

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [devel] судьба одного пакета (rpm-build-lua)

[Gleb Fotengauer-Malinovskiy]

[-- Attachment #1: Type: text/plain, Size: 1909 bytes --]

Hi,

On Mon, Jul 28, 2025 at 07:44:09PM +0500, Ildar Mulyukov wrote:
> не знаю точно, к кому обратиться, поэтому пишу сюда. Не ради флейма.
> Отвечать можно и приватно. Спасибо.
> 
> Пакет rpm-build-lua был изначально создан Владимиром Селезнёвым и был
> в ACL закрыт для всех, кроме автора. Владимир отстранился от ALT, так
> что пакет остался без доступа.
> 
> Я написал приватно, и парни из Базальт почему-то отдали пакет Данилу
> (Daniel Zagaynov). Я, честно говоря, не понял, из каких соображений.

Это решение было принято самим Владимиром, который передал Даниле в т.ч.
сами интерпретаторы lua.

> Теперь мои версии пакета ждут его апрува. Последний уже больше трёх месяцев.

Я так понимаю, что проблема лежит не в области выдачи аппрува, а в области
согласия с тем изменением, которое вы предлагаете.  И, насколько я вижу, в
недопонимании связанным с несогласием по этому изменению.

Насколько я вижу, это изменение добавляет в пакеты дополнительные
Provides. Есть ли план делать в пакетах зависимости на эти новые Provides?
Потому что без зависимостей, Provides сами по себе не нужны (и даже
вредны).

-- 
glebfm

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [devel] судьба одного пакета (rpm-build-lua)

[Ildar Mulyukov]

Добрый новый день!

On Tue, Jul 29, 2025 at 1:33 PM Gleb Fotengauer-Malinovskiy
<glebfm@altlinux.org> wrote:
> On Mon, Jul 28, 2025 at 07:44:09PM +0500, Ildar Mulyukov wrote:
> > Я написал приватно, и парни из Базальт почему-то отдали пакет Данилу
> > (Daniel Zagaynov). Я, честно говоря, не понял, из каких соображений.
>
> Это решение было принято самим Владимиром, который передал Даниле в т.ч.
> сами интерпретаторы lua.

Любопытная деталь. За полгода этой сантабарбары она ещё не всплывала.

> > Теперь мои версии пакета ждут его апрува. Последний уже больше трёх месяцев.
>
> Я так понимаю, что проблема лежит не в области выдачи аппрува, а в области
> согласия с тем изменением, которое вы предлагаете. И, насколько я вижу, в
> недопонимании связанным с несогласием по этому изменению.

Как хорошо, что Вы это понимаете и знаете. Вот мне об этом ни Данила,
ни Вы как-то не сообщили. Телепатия у меня развита слабо, уж извините.

О том, что вообще новые Provides вызывают какие-то проблемы, я узнал
только от Миши Шигорина недавно и только потому, что спросил его по
старой памяти (практически втянул непричастного. У нас с ним как-то
сложились отношения за эти годы, точнее десятилетия в ALT).

> Насколько я вижу, это изменение добавляет в пакеты дополнительные
> Provides.

Это не дополнительные Provides. Это те же самые Provides, которые там
уже годами сидят. Просто это изменение будет их создавать
автоматически, в количестве 1 шт. на пакет LuaRocks. Объяснения об
этом я уже давал Даниле больше двух месяцев назад. И Вы, Глеб,
совершенно точно в курсе, т.к. стояли в копии.

> Есть ли план делать в пакетах зависимости на эти новые Provides?

Старые.

> Потому что без зависимостей, Provides сами по себе не нужны (и даже
> вредны).

Как я писал выше (вчера), Requires создаются полуавтоматически
утилитой lrimport. Сделать автоматическое опакечивание LuaRocks я
сейчас не потяну.

С уважением, Ильдар
--
Ildar Mulyukov,
(ΙΧΘΥΣ) child of God

email: ildar.mulyukov@gmail.com
matrix: @ildar:matrix.org
blog: http://johan-notes.blogspot.com/

Re: [devel] судьба одного пакета (rpm-build-lua)

[Dmitry V. Levin]

Hi,

On Tue, Jul 29, 2025 at 03:09:17PM +0500, Ildar Mulyukov wrote:
> Добрый новый день!
> 
> On Tue, Jul 29, 2025 at 1:33 PM Gleb Fotengauer-Malinovskiy wrote:
> > On Mon, Jul 28, 2025 at 07:44:09PM +0500, Ildar Mulyukov wrote:
> > > Я написал приватно, и парни из Базальт почему-то отдали пакет Данилу
> > > (Daniel Zagaynov). Я, честно говоря, не понял, из каких соображений.
> >
> > Это решение было принято самим Владимиром, который передал Даниле в т.ч.
> > сами интерпретаторы lua.
> 
> Любопытная деталь. За полгода этой сантабарбары она ещё не всплывала.
> 
> > > Теперь мои версии пакета ждут его апрува. Последний уже больше трёх месяцев.
> >
> > Я так понимаю, что проблема лежит не в области выдачи аппрува, а в области
> > согласия с тем изменением, которое вы предлагаете. И, насколько я вижу, в
> > недопонимании связанным с несогласием по этому изменению.
> 
> Как хорошо, что Вы это понимаете и знаете. Вот мне об этом ни Данила,
> ни Вы как-то не сообщили. Телепатия у меня развита слабо, уж извините.
> 
> О том, что вообще новые Provides вызывают какие-то проблемы, я узнал
> только от Миши Шигорина недавно и только потому, что спросил его по
> старой памяти (практически втянул непричастного. У нас с ним как-то
> сложились отношения за эти годы, точнее десятилетия в ALT).
> 
> > Насколько я вижу, это изменение добавляет в пакеты дополнительные
> > Provides.
> 
> Это не дополнительные Provides. Это те же самые Provides, которые там
> уже годами сидят. Просто это изменение будет их создавать
> автоматически, в количестве 1 шт. на пакет LuaRocks. Объяснения об
> этом я уже давал Даниле больше двух месяцев назад. И Вы, Глеб,
> совершенно точно в курсе, т.к. стояли в копии.

Прошу прощения, я правильно понимаю, что у этой истории было ещё и полгода
предыстории, о которой подписчики devel@ не в курсе?  Что, оказывается,
были какие-то частные переписки на эту тему, о существовании и содержании
которых остальным ничего не известно?

Если это так, то было бы логично предложить участникам этой истории
поделиться недостающими деталями.


-- 
ldv

Re: [devel] судьба одного пакета (rpm-build-lua)

[Ildar Mulyukov]

Добрый день,

On Tue, Jul 29, 2025 at 4:24 PM Dmitry V. Levin <ldv@altlinux.org> wrote:
> Прошу прощения, я правильно понимаю, что у этой истории было ещё и полгода
> предыстории, о которой подписчики devel@ не в курсе?  Что, оказывается,
> были какие-то частные переписки на эту тему, о существовании и содержании
> которых остальным ничего не известно?
>
> Если это так, то было бы логично предложить участникам этой истории
> поделиться недостающими деталями.

Частная переписка не несла в себе ничего содержательного (по моему
мнению), поэтому оставалась частной.
1. Когда Владимир Селезнев перестал отвечать (около полугода назад), я
написал письмо (https://lore.altlinux.org/devel/CACAYGhtLjGzkd6DvMf+agaxM50YE8xu7woevy+tcxT_QWtMpaw@mail.gmail.com/),
после чего владелец пакета сменился.
2. Данила спросил о деталях новой версии и я ему в 4 письмах обосновал
изменения в версии 0.5-alt2
3. Затем Владимир (да, снова появился) попросил добавить записи о том,
что я правил исходники, и я их добавил.
4. После чего Данила заапрувил мне 0.5-alt2
5. Начиная с 18 апреля я запрашиваю разрешение на задание 381946
6. После ряда вопросов и ответов от Данилы он пропал (последнее от
него письмо 7 мая) и больше на мои письма не отвечает.
7. Через месяц безответных писем я начинаю беспокоиться и ставлю в
копию Мишу Шигорина ("Пошлю Мишу; может быть, увидев его,
постыдятся").
8. С тех пор только Миша мне отвечал и сообщил о каких-то проблемах с
Provides. Всё.

По желанию вышлю всю переписку в личку.
-- 
Ildar Mulyukov,
(ΙΧΘΥΣ) child of God

email: ildar.mulyukov@gmail.com
matrix: @ildar:matrix.org
blog: http://johan-notes.blogspot.com/

Re: [devel] судьба одного пакета (rpm-build-lua)

[Gleb Fotengauer-Malinovskiy]

[-- Attachment #1: Type: text/plain, Size: 3460 bytes --]

On Tue, Jul 29, 2025 at 03:09:17PM +0500, Ildar Mulyukov wrote:
> Добрый новый день!
> 
> On Tue, Jul 29, 2025 at 1:33 PM Gleb Fotengauer-Malinovskiy
> <glebfm@altlinux.org> wrote:

[...]
Я предлагаю оставить часть про разбор личных переписок, которые не привели
к договорённости.  devel@, конечно же, самое место, чтобы обсуждать такие
вещи, если люди не договорились (и полгода ждать не надо).

> О том, что вообще новые Provides вызывают какие-то проблемы, я узнал

Любые бессмысленные (или, по крайней мере, кажущиеся таковыми с первого
взгляда) сущности вызывают вопрос «зачем?».

> > Насколько я вижу, это изменение добавляет в пакеты дополнительные
> > Provides.
> 
> Это не дополнительные Provides. Это те же самые Provides, которые там
> уже годами сидят. Просто это изменение будет их создавать
> автоматически, в количестве 1 шт. на пакет LuaRocks.

Ручные зависимости, которые выглядят так, будто они автоматические это
неправильно. Так что либо нужно их убрать, либо автоматизировать, тут я
согласен.

> > Есть ли план делать в пакетах зависимости на эти новые Provides?
> 
> Старые.

Вопрос был про Requires, сейчас таких Requires нет ни в одном пакете, так
что они могут быть только новыми.

> > Потому что без зависимостей, Provides сами по себе не нужны (и даже
> > вредны).
> 
> Как я писал выше (вчера), Requires создаются полуавтоматически
> утилитой lrimport.

Я не вижу, чтобы на пакетах это как-то отражалось, таких Requires в
пакетах нет.

Я так понимаю, что ответ такой, что эти Provides нужны только для
BuildRequires, а для Requires не нужны. Если это так, то нужно внести эту
информацию в коммит мессадж (это и есть ответ на вопрос «зачем».)

Но тут же возникает другой вопрос: нужны ли нам эти Provides или проще
исправить один пакет (переименовать lua5.4-module-lualanes ->
lua5.4-module-lanes) и внести в Полиси требование называть пакеты с
lua-модулями lua<lua_ver>-module-<luarocks_name>? Считаем ли мы возможными
исключения из этого правила?

Потому что если мы можем сделать такое требование, то какая разница между
BuildRequires: luarocks5.X(Y)
и
BuildRequires: lua5.X-module-Y
?

-- 
glebfm

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [devel] судьба одного пакета (rpm-build-lua)

[Ildar Mulyukov]

Глеб,

большое спасибо, это письмо даёт чуть более свежий взгляд на данный вопрос.

On Tue, Jul 29, 2025 at 9:21 PM Gleb Fotengauer-Malinovskiy
<glebfm@altlinux.org> wrote:
> > > Есть ли план делать в пакетах зависимости на эти новые Provides?
> >
> > Старые.
>
> Вопрос был про Requires, сейчас таких Requires нет ни в одном пакете, так
> что они могут быть только новыми.
> > > Потому что без зависимостей, Provides сами по себе не нужны (и даже
> > > вредны).
> > Как я писал выше (вчера), Requires создаются полуавтоматически
> > утилитой lrimport.
>
> Я не вижу, чтобы на пакетах это как-то отражалось, таких Requires в
> пакетах нет.
>
> Я так понимаю, что ответ такой, что эти Provides нужны только для
> BuildRequires, а для Requires не нужны.

В этом смысле зависимости `luarocks` (предмет обсуждения) больше
похожи на наши `pkg-config(LIB)`.

Если всерьёз посмотреть на `pkg-config(LIB)`, то на них, конечно,
больше зависимостей в BuildRequires, хотя есть и Requires: в -devel
подпакетах.

> Если это так, то нужно внести эту
> информацию в коммит мессадж (это и есть ответ на вопрос «зачем».)

Не проблема, конечно.

> Но тут же возникает другой вопрос: нужны ли нам эти Provides или проще
> исправить один пакет (переименовать lua5.4-module-lualanes ->
> lua5.4-module-lanes) и внести в Полиси требование называть пакеты с
> lua-модулями lua<lua_ver>-module-<luarocks_name>? Считаем ли мы возможными
> исключения из этого правила?
>
> Потому что если мы можем сделать такое требование, то какая разница между
> BuildRequires: luarocks5.X(Y)
> и
> BuildRequires: lua5.X-module-Y
> ?

Процитирую самого себя из прошлого письма:
> Действительно, технически можно было бы отказаться от искусственной зависимости (luarocks5.1(basexx)) в пользу стандартной пакетной (lua5.1-module-basexx). Но тут сразу видно аккуратно разложенные грабли: ошибка в имени пакета, пакет с нужным именем, но без luarocks-содержимого и т.п.
>
> Хорошо бы понять что мы экономим и зачем.

и, да, с таким подходом можно и от `pkg-config(LIB)` отказаться ;-)

С уважением,
-- 
Ildar Mulyukov,
(ΙΧΘΥΣ) child of God

email: ildar.mulyukov@gmail.com
matrix: @ildar:matrix.org
blog: http://johan-notes.blogspot.com/

Re: [devel] судьба одного пакета (rpm-build-lua)

[Gleb Fotengauer-Malinovskiy]

[-- Attachment #1: Type: text/plain, Size: 3647 bytes --]

On Tue, Jul 29, 2025 at 10:02:45PM +0500, Ildar Mulyukov wrote:
> On Tue, Jul 29, 2025 at 9:21 PM Gleb Fotengauer-Malinovskiy
> <glebfm@altlinux.org> wrote:
> > Я так понимаю, что ответ такой, что эти Provides нужны только для
> > BuildRequires, а для Requires не нужны.
> 
> В этом смысле зависимости `luarocks` (предмет обсуждения) больше
> похожи на наши `pkg-config(LIB)`.
> 
> Если всерьёз посмотреть на `pkg-config(LIB)`, то на них, конечно,
> больше зависимостей в BuildRequires, хотя есть и Requires: в -devel
> подпакетах.

Но поскольку нет ничего похожего на -devel подпакеты, то мы говорим только
про BuildRequires, верно?

> > Если это так, то нужно внести эту
> > информацию в коммит мессадж (это и есть ответ на вопрос «зачем».)
> 
> Не проблема, конечно.
> 
> > Но тут же возникает другой вопрос: нужны ли нам эти Provides или проще
> > исправить один пакет (переименовать lua5.4-module-lualanes ->
> > lua5.4-module-lanes) и внести в Полиси требование называть пакеты с
> > lua-модулями lua<lua_ver>-module-<luarocks_name>? Считаем ли мы возможными
> > исключения из этого правила?
> >
> > Потому что если мы можем сделать такое требование, то какая разница между
> > BuildRequires: luarocks5.X(Y)
> > и
> > BuildRequires: lua5.X-module-Y
> > ?
> 
> Процитирую самого себя из прошлого письма:
> > Действительно, технически можно было бы отказаться от искусственной зависимости (luarocks5.1(basexx)) в пользу стандартной пакетной (lua5.1-module-basexx). Но тут сразу видно аккуратно разложенные грабли: ошибка в имени пакета, пакет с нужным именем, но без luarocks-содержимого и т.п.
> >
> > Хорошо бы понять что мы экономим и зачем.
> 
> и, да, с таким подходом можно и от `pkg-config(LIB)` отказаться ;-)

Я не просто так спрашивал про однозначность, потому что тут кажется, что
мы могли бы её обеспечить, а в случае pkg-config она невозможна
(pkg-config(LIB) очень часто не находится в пакете libLIB-devel).

Но я всё равно вижу смысл в том, чтобы постараться обеспечить
однозначность (в том числе, можно реализовать проверку), но это будет
совсем просто, если мы на самом деле хотим двигаться в сторону
автоматизации/роботизации сборки пакетов lua из luarocks.

Но лично меня вы убедили, что от этих Provides и такого их использования в
любом случае не будет никакого вреда.

-- 
glebfm

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]