Re: [devel] Модули python3

[Ivan Zakharyaschev <imz@altlinux.org>]

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

Hello!

On Wed, 28 Mar 2018, Aleksei Nikiforov wrote:

>>  Во-первых, из-за стремления к политике поддерживать только один вариант в
>>  Сизифе. С этим все согласились и при последней пересборке с python 3.5.
>> 
>
> Временная сборка модулей питона для нескольких версий питона при апгрейде до 
> новой версии питона не является поддержкой нескольких версий питона. Это 
> скорее удобство для обновления, временная мера при обновлении, а не 
> постоянное состояние репозитория :). В текущей сборке обновление неудобно 
> делать: сейчас нужно всё обновлять одним огромным заданием, а сборку модулей 
> под несколько версий можно делать постепенно.

Да, в принципе можно так. Такой подход даже не будет мешать старому: можно 
постепенно собирать новые модули с новым форматом Requires+Provides и они 
не будут мешать старому питону.

>>  Во-вторых, технически это тогда должно было бы реализовываться по-другому.
>>  Если noarch-пакеты общие, как сейчас, т.е. подходят для использования
>>  любой версией python3, то механизм Requires+Provides в rpm не позволяет
>>  выразить нужные условия работоспособности. Например:
>>
>>  модуль a импортирует noarch-модуль b, b импортирует c.
>>
>>  a и с -- бинарные.
>>
>>  Тогда когда импортируется a для python 3.6, должен импортироваться b, а
>>  потом c для python 3.6 тоже. И так же для python 3.5. Соответсвующий
>>  Requires в пакете с модулем b невозможно написать.
>>
>>  Раз так не получается, остаётся только сборка каждого модуля для каждой
>>  версии питона, т.е. все-все-все модули в Сизифе надо будет собрать ещё
>>  раз. Ну и этого может не хотеться, например, потому что слишком долгий
>>  процесс, если делать вручную.
>
> Это единственный минус такого подхода, который я сейчас вижу: noarch пакеты 
> тоже придётся пересобирать (ради обновления requires+provides).
> Но сделать так, чтобы был только один noarch пакет модулей, а не по одному на 
> каждую версию питона, вполне можно. Содержимое noarch модулей может также 
> лежать в %_libexecdir/python3 для всех версий, просто provides+requires 
> обновится.
>
> Сначала собираем новый python (3.6), затем мы собираем постепенно все модули 
> и для python 3.5, и для 3.6. Раз зависимости идут 'a -> b (noarch) -> c', то 
> сначала надо собирать 'c'. Если попытаться собрать 'a', то в репозиторий 
> сборка не пройдёт из-за недостатка зависимостей: 'b' предоставляет только 
> зависимости для python 3.5, но не для python 3.6 - пакет 'b' ещё не был 
> пересобран, а пакет 'a' уже потребует зависимости и для 3.5, и для 3.6 после 
> пересборки. Пакет 'b' тоже нельзя пересобрать из-за той же проблемы: у пакета 
> 'c' нет Provides для python 3.6, есть только для python 3.5.
> Таким образом пересобирается пакет 'c' (предварительно, допустим, все его 
> зависимости пересобрали) для python 3.5 и 3.6, у него появились Provides для 
> этих двух версий, и теперь можно пересобрать пакет 'b', а затем - 'a'.

Как-то неестественно иметь один файл, но два Requires -- для python3.5 и 
python3.6. По смыслу это скорее ИЛИ, а не И. Тогда уж лучше разделять на 
две копии, больше гибкости при установке.

Было бы удобнее собирать варианты, если бы пакеты уже перешли на сборку 
вариантов с помощью specsubst (а не дублированием похожих команд в одном 
спеке). Пример: python{,3}-module-enchant. girar-nmu только плохо умеет 
такую схему, но можно же доделать и сделать girar-nmu лучше. (У меня ещё 
мои скрипты похожего назначения, их я сразу писал с мыслью о specsubst, но 
без мысли об srpm.)

> А когда все пакеты будут собраны и с python 3.5, и с 3.6, работа пойдёт в 
> обратном направлении - постепенно пересобрать все пакеты без python 3.5.
>
> Это, конечно, много пересборок пакетов, и работа по первоначальной поддержке 
> другой схемы сборки модулей, но и текущее состояние не лишено минусов: задача 
> обновления тоже огромная, её и подготовка и выполнение занимают немало 
> времени, и должна эта задача за один заход завершиться успешно, что, учитывая 
> размер такого задания, а у меня сейчас получается под 300 пакетов, довольно

Последняя история, да, что между 200 и 300 было:

https://lists.altlinux.org/pipermail/sisyphus-incominger/2016-April/433058.html
http://git.altlinux.org/tasks/archive/done/_155/159698/logs/events.49.2.log

> маловероятное событие. Даже если попросить ничего не обновлять в репозитории,

Да питон-модули в основном всё равно никто годами не обновляет, за 
исключением массовых набегов роботов и не совсем.

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

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

Я тогда использовал girar-nmu. (Для следующей массовой задаче по 
переписыванию спеков и сборке сделал свои скрипты, которые мне были более 
удобны, но их в виде пакета не опубликовал. Они больше для работы только с 
gear.)

> В итоге, сейчас обновление python3 - тоже небыстрый процесс. Возможно, 
> пересборка всех модулей и дольше, но она возможна небольшими заданиями по 
> несколько пакетов за раз, что позволяет выполнять эту работу параллельно с 
> остальными изменениями в репозитории, т.е. 
> обновлениями/удалениями/добавлениями других пакетов, которые как-либо 
> взаимодействуют с python3. С текущим подходом к обновлению python3 
> параллельная работа с репозиторием значительно снижает вероятность успеха 
> такого обновления, соответственно увеличивая время этого обновления.

Лично мне было бы проще ещё раз по последней схеме обновить, потому что 
трудности на этом пути уже проходил и проще вспомнить и понять, что 
происходит. Не хотелось бы делать это самому, хотелось делиться этим 
опытом с новыми людьми.

Ещё тут такое свойство могу отметить: желание иметь полный набор модулей 
для нового python3 тут просто превращается в требование по отсутствию 
unmet-ов, проверяемое сборочницей. Т.е. не так, что человек держит в 
голове или в своих записках, что ещё стоит собрать, а эта информация 
вычисляется и одинаково на виду у всех мейнтейнеров.

>
>>
>>  Теоретически, конечно, всякие варианты возможно, но у нас сейчас такой
>>  выбран. Вероятно, в Debian по-другому. В Сизифе тоже были предусмотрены
>>  такие механизмы для размножения модулей, остались атавизмы в виде всяких
>>  %python_setup_module, которые сейчас не очень полезны. (И этого уже нет
>>  для Python 3.)
>>
>>
>>
>>  _______________________________________________
>>  Devel mailing list
>>  Devel@lists.altlinux.org
>>  https://lists.altlinux.org/mailman/listinfo/devel
>> 
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel
>