ALT Linux Team development discussions
 help / color / mirror / Atom feed
From: Ivan Zakharyaschev <imz@altlinux.org>
To: ALT Linux Team development discussions <devel@lists.altlinux.org>
Subject: Re: [devel] Модули python3
Date: Wed, 28 Mar 2018 12:06:54 +0300 (MSK)
Message-ID: <alpine.LFD.2.20.1803281131500.3361@imap.altlinux.org> (raw)
In-Reply-To: <8eb6f648-26d8-c2b2-6fe1-b387ada32705@basealt.ru>

[-- 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
>

  reply	other threads:[~2018-03-28  9:06 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-27 15:43 Aleksei Nikiforov
2018-03-27 17:30 ` Ivan Zakharyaschev
2018-03-28  8:11   ` Aleksei Nikiforov
2018-03-28  9:06     ` Ivan Zakharyaschev [this message]
2018-03-28  9:48       ` Igor Vlasenko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.LFD.2.20.1803281131500.3361@imap.altlinux.org \
    --to=imz@altlinux.org \
    --cc=devel@lists.altlinux.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

ALT Linux Team development discussions

This inbox may be cloned and mirrored by anyone:

	git clone --mirror http://lore.altlinux.org/devel/0 devel/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 devel devel/ http://lore.altlinux.org/devel \
		devel@altlinux.org devel@altlinux.ru devel@lists.altlinux.org devel@lists.altlinux.ru devel@linux.iplabs.ru mandrake-russian@linuxteam.iplabs.ru sisyphus@linuxteam.iplabs.ru
	public-inbox-index devel

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://lore.altlinux.org/org.altlinux.lists.devel


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git