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 >