From: Aleksei Nikiforov <darktemplar@basealt.ru> To: devel@lists.altlinux.org Subject: Re: [devel] Модули python3 Date: Wed, 28 Mar 2018 11:11:10 +0300 Message-ID: <8eb6f648-26d8-c2b2-6fe1-b387ada32705@basealt.ru> (raw) In-Reply-To: <alpine.LFD.2.20.1803272017220.3361@imap.altlinux.org> Здравствуйте. 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 >
next prev parent reply other threads:[~2018-03-28 8:11 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 [this message] 2018-03-28 9:06 ` Ivan Zakharyaschev 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=8eb6f648-26d8-c2b2-6fe1-b387ada32705@basealt.ru \ --to=darktemplar@basealt.ru \ --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