From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on sa.local.altlinux.org X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=ALL_TRUSTED,BAYES_00, FUZZY_XPILL,RP_MATCHES_RCVD autolearn=no autolearn_force=no version=3.4.1 To: devel@lists.altlinux.org References: <451596a9-1fb1-25a0-91d6-6a5d1551329a@basealt.ru> From: Aleksei Nikiforov Message-ID: <8eb6f648-26d8-c2b2-6fe1-b387ada32705@basealt.ru> Date: Wed, 28 Mar 2018 11:11:10 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=koi8-r; format=flowed Content-Language: ru Content-Transfer-Encoding: 8bit Subject: Re: [devel] =?utf-8?b?0JzQvtC00YPQu9C4IHB5dGhvbjM=?= X-BeenThere: devel@lists.altlinux.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ALT Linux Team development discussions List-Id: ALT Linux Team development discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2018 08:11:15 -0000 Archived-At: List-Archive: List-Post: Здравствуйте. 27.03.2018 20:30, Ivan Zakharyaschev пишет: > Hello! > > On Tue, 27 Mar 2018, Aleksei Nikiforov wrote: > >> Я пытаюсь разобраться с обновлением python3 до версии 3.6.x и возник >> вопрос: почему архитектурно-зависимые модули python3 в основном лежат >> в % _libdir/python3 вместо %_libdir/python3.5? Если бы модули лежали в >> % _libdir/python3.5, то рядом в %_libdir/python3.6 можно было бы >> положить модули для python-3.6.x, а в будущем и для 3.7.x, а сейчас >> обновление python-3 невозможно без одномоментной пересборки всего >> содержимого %_libdir/python3 c новой версией python3. > > Не совсем так. Только бинарных модулей. > Да, действительно. > Во-первых, из-за стремления к политике поддерживать только один вариант > в Сизифе. С этим все согласились и при последней пересборке с python 3.5. > Временная сборка модулей питона для нескольких версий питона при апгрейде до новой версии питона не является поддержкой нескольких версий питона. Это скорее удобство для обновления, временная мера при обновлении, а не постоянное состояние репозитория :). В текущей сборке обновление неудобно делать: сейчас нужно всё обновлять одним огромным заданием, а сборку модулей под несколько версий можно делать постепенно. > Во-вторых, технически это тогда должно было бы реализовываться > по-другому. Если 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'. А когда все пакеты будут собраны и с python 3.5, и с 3.6, работа пойдёт в обратном направлении - постепенно пересобрать все пакеты без python 3.5. Это, конечно, много пересборок пакетов, и работа по первоначальной поддержке другой схемы сборки модулей, но и текущее состояние не лишено минусов: задача обновления тоже огромная, её и подготовка и выполнение занимают немало времени, и должна эта задача за один заход завершиться успешно, что, учитывая размер такого задания, а у меня сейчас получается под 300 пакетов, довольно маловероятное событие. Даже если попросить ничего не обновлять в репозитории, есть немаленькая вероятность, что с первого раза такое огромное задание не пройдёт всё равно. Куча более мелких заданий для постепенной сборки модулей питона для новой версии лишено этого весомого на мой взгляд недостатка. В итоге, сейчас обновление python3 - тоже небыстрый процесс. Возможно, пересборка всех модулей и дольше, но она возможна небольшими заданиями по несколько пакетов за раз, что позволяет выполнять эту работу параллельно с остальными изменениями в репозитории, т.е. обновлениями/удалениями/добавлениями других пакетов, которые как-либо взаимодействуют с python3. С текущим подходом к обновлению python3 параллельная работа с репозиторием значительно снижает вероятность успеха такого обновления, соответственно увеличивая время этого обновления. > > Теоретически, конечно, всякие варианты возможно, но у нас сейчас такой > выбран. Вероятно, в Debian по-другому. В Сизифе тоже были предусмотрены > такие механизмы для размножения модулей, остались атавизмы в виде всяких > %python_setup_module, которые сейчас не очень полезны. (И этого уже нет > для Python 3.) > > > > _______________________________________________ > Devel mailing list > Devel@lists.altlinux.org > https://lists.altlinux.org/mailman/listinfo/devel >