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

[Denis Medvedev <nbr@altlinux.org>]

On Tue, 31 Mar 2026 13:29:33 +0300
Stanislav Levin <slev@altlinux.org> wrote:

> 
> 
> 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 макросы *мне* не представляется тривиальной 
> задачей.
> 
> Таким образом,
> выражается негативное личное мнение и вся "конструктивная" критика 
> сводится к "все было хорошо, что-то поменялось, не хочется разбираться и 
> верните как было".
> 
> 



--