[devel] Массовая, вероломная и необоснованная кража пакетов

[Stanislav Levin]

On 3/31/26 12:04 PM, Anton Midyukov wrote:
> 30.03.2026 20:58, Anton Farygin пишет:
>> On 3/30/26 20:48, Evgeny Sinelnikov wrote:
>>> Когда же аргументы не выглядят убедительно, то никаких других мер не
>>> видно. А это уже вопрос готовности в таком виде сопровождать python, в
>>> принципе. Наверное, так стоило поставить вопрос.
>>
>> Большая экосистема с множеством ментейнеров должна регулироваться не письмами в рассылке а зафиксированной политикой сборки пакетов.
>>
>> В случае отсутствия единой политики - всегда найдётся кто-то, кто хочет сделать свою работу по сопровождению пакетов проще (на его взгляд, конечно) и обвяжет это каким-то инструментарием.
>>
>> К счастью этот инструментарий документированный, открытый, публичный и его можно обсуждать и развивать и им удобно пользоваться.
>>
>> Но до сих пор нет ни одного конструктивного замечания как к документации, так и к макросам:
>>
>> https://www.altlinux.org/Python_packaging_guide
>>
> 
> Почему статья на английском языке?
0) почему нет?
1) ожидалось участие не только русскоговорящих
2) большинство терминов англоязычных
3) *мне* так больше *нравится*
4) пока что никто не просил перевести

> Автор статьи не знает русского языка?
никто не знает его в совершенстве ;)

> Для статей на английском языке есть en.altlinux.org
> Или это не уважение к сообществу со стороны автора?
неуважение - это требование чего-то.

Согласен, что лучше перенести на англоязычную вики и сделал бы, но как 
тогда, так и сейчас не удается завершить регистрацию (не работает).

> 
> и конструктивная критика была:
> https://lore.altlinux.org/devel/ff5f2ad9-e94d-4ea8-afde-e507164c9875@altlinux.org/
> 

Простите, но не удается найти "объективную" и "конструктивную" критику 
или вопросы. Наверное, проблема в недостаточном знании русского :(

 > 1.) Данный подход полностью ломает идею спек-файла, который по
оригинальной задумке должен хранить _всю_ информацию о пакете. То есть
открыв спек-файл нельзя определить его зависимости, в поиске по спекам
нельзя отгрепать зависимости и так далее.

Чью идею? Кто так решил? Что такое оригинальная задумка? И главный 
вопрос - а почему подходы и взгляды не могут быть изменены со временем?

 > 2.) Спек превращается в результат автогенерации бесчисленного количества
макросов. Раньше подобным автогенератам было место в репозитории
Autoimports, в сизиф же пропускались "очеловеченные" спеки, которые
доступны для чтения и понимания участникам сообщества. Перефразируя
Мартина Фаулера "Скрипты могут писать спеки, понятные сборочнице,
хорошие мейнтейнеры пишут спеки понятные людям".

Это личное мнение, которое уважаю и принимаю, но это *личное* мнение.

 > 3.) Проблемы с бэкпортами. Вспоминаем сколько спотыкались о другую
"инновационную разработку" под названием ubt.

Абстрактные проблемы, которые не были озвучены. Плюс очевидная попытка 
флеймить про zerg's ubt ;)

 > 4.) Автоматическая генерация зависимостей очевидно порождает мусор.
Поэтому в 180 пакетах из 560 присутствуют костыли под названием
*_filter, которые призваны отфильтровывать список зависимостей. То есть
вместо списка зависимостей, в спеке идёт список _независимостей_.

Автор выражает свое личное мнение, используя усиление конструкции через 
"очевидно". Нет попытки анализа применения фильтров зависимостей, 
которые могут применяться по нескольким причинам. Среди основных
я бы выделил:
- зависимости нет в репозитории и она опциональная
- отсутствие необходимости в зависимости и желание соптимизировать

То есть это - очень *валидные* причины.

 > 5.) В текущем состоянии наш замечательный репозиторий сизифа потерял
консистентность в области питоновских пакетов. Очевидно, что для
обновления или исправления одних пакетов зачастую приходится влезать в
другие. Далеко не у всех есть желание разбираться в модулях собранных
этим необычным способом. Так, например, за последний год было
_испорчено_ несколько ключевых модулей, для бутстрапа нового питона.
Ручки бутстрапа оторваны, списки зависимостей переделаны в
автоматическом режиме, хотя раньше всё было чётко выверено.

"очевидно", "не у всех есть желание", "необычным способом", "испорчено", 
"раньше всё было" - маркеры личного субъективного мнения.

 > Автору данного подхода рекомендую доделать свою автоматику таким
образом, чтобы ей можно было пользоваться добровольно. То есть написать
скрипт таким образом, чтобы он из существующих файлов со спецификациями
зависимостей выдирал всё необходимое как сейчас, но добавлял их не в
отдельный json-файл а в привычном для всех виде как BuildRequires в
спек-файле. Я такое уже реализовывал для обновления библиотек openstack.

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

Технически, зависимости формата pep508 резолвятся в конкретном окружении
и *могут* зависеть от множества факторов (например, самые популярные - 
это версия питона и архитектура), поэтому переложить логику маркеров 
зависимостей на условные RPM макросы *мне* не представляется тривиальной 
задачей.

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


----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя     : OpenPGP_signature.asc
Тип     : application/pgp-signature
Размер  : 840 байтов
Описание: OpenPGP digital signature
Url     : <http://lists.altlinux.org/pipermail/devel/attachments/20260331/21effb1f/attachment-0001.bin>