[devel] Спасём python3 вместе! (действительно) - Stable ABI

[devel] Спасём python3 вместе! (действительно) - Stable ABI

[Anton Zhukharev]

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

Всем привет!

Последние таски по обновлению Python выглядят пугающее: объем
пересобираемых пакетов невероятно огромный и постоянно растет из-за чего
обновление самого Python в Sisyphus происходит дольше, чем в апстриме...

Я прошу обратить внимание на эту проблему куда большую часть сообщества
и принять хоть какое-нибудь решение, которое не оставит все как есть.

А под "хоть какое-нибудь решение" я имею ввиду единственное, на данный
момент предложенное. Читать тут:
https://bugzilla.altlinux.org/show_bug.cgi?id=55340#c5
https://bugzilla.altlinux.org/56201

Сейчас чуть подробнее введу в курс (небольшая, но важная выжимка из
https://docs.python.org/3/c-api/stable.html).

* Stable ABI — это набор символов в CPython, которые остаются бинарно-
  совместимыми для различных минорных версий Python 3.X. Экстеншн,
  собранный под Stable ABI (и правильно использующий Limited API),
  должен работать без пересборки на всех минорных версиях Python,
  начиная с той, для которой он был скомпилирован.
  Такие модули часто имеют в имени файла тег abi3
  (например, mymodule.abi3.so)

* Limited C API — это подмножество C API Python, использование
  которого гарантирует совместимость с Stable ABI.

* Интерпретатор Python не проверяет, действительно ли модуль с тегом
  abi3 соответствует Stable ABI. Ответственность за обеспечение
  корректности лежит на мейнтейнере.

В Sisyphus сейчас есть модули с тэгом abi3 (будем надеятся, что они
соблюдают Stable ABI) и собранные для конкретной минорной версии
Python. Текущая идея сборки компилируемых модулей заключается в том,
чтобы везде ставить зависимость на %python3_ABI_dep. Естественно, это
приводит к тому, что у нас сейчас при обновлении Python мучается один
бедный grenka, а все сидят и смотрят на это в ожидании окончания
(кто-то даже успевает продлять ему муки).

В общем, идея решения заключается в том, чтобы для модулей, собираемых
под Stable ABI эту зависимость не генерировать и как-нибудь проверять,
что там действительно Stable ABI. Для этого есть инструмент abi3audit,
собираемый в этом задании: https://packages.altlinux.org/tasks/396283

-- 
Anton Zhukharev
ALT Linux Team

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [devel] Спасём python3 вместе! (действительно) - Stable ABI

[Grigory Ustinov]

02.10.2025 16:44, Anton Zhukharev пишет:
> Всем привет!
>
> Последние таски по обновлению Python выглядят пугающее: объем
> пересобираемых пакетов невероятно огромный и постоянно растет из-за чего
> обновление самого Python в Sisyphus происходит дольше, чем в апстриме...
Меня объём пересобираемых пакетов не пугает. Обновление самого Python в 
Sisyphus происходит дольше по абсолютно другим причинам.
> Я прошу обратить внимание на эту проблему куда большую часть сообщества
> и принять хоть какое-нибудь решение, которое не оставит все как есть.
>
> А под "хоть какое-нибудь решение" я имею ввиду единственное, на данный
> момент предложенное.
Вот из-за таких "хоть каких-нибудь решений" обновление Python и затянулось.
> В Sisyphus сейчас есть модули с тэгом abi3 (будем надеятся, что они
> соблюдают Stable ABI) и собранные для конкретной минорной версии
> Python. Текущая идея сборки компилируемых модулей заключается в том,
> чтобы везде ставить зависимость на %python3_ABI_dep. Естественно, это
> приводит к тому, что у нас сейчас при обновлении Python мучается один
> бедный grenka, а все сидят и смотрят на это в ожидании окончания
> (кто-то даже успевает продлять ему муки).
>
> В общем, идея решения заключается в том, чтобы для модулей, собираемых
> под Stable ABI эту зависимость не генерировать и как-нибудь проверять,
> что там действительно Stable ABI. Для этого есть инструмент abi3audit,
> собираемый в этом задании: https://packages.altlinux.org/tasks/396283
Я правильно понимаю, что всё что выше написано касается всего 38 пакетов?

Re: [devel] Спасём python3 вместе! (действительно) - Stable ABI

[Anton Zhukharev]

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

On Thu, Oct 02, 2025 at 10:45:34PM +0300, Grigory Ustinov wrote:
> 02.10.2025 16:44, Anton Zhukharev пишет:
> > Всем привет!
> >
> > Последние таски по обновлению Python выглядят пугающее: объем
> > пересобираемых пакетов невероятно огромный и постоянно растет из-за чего
> > обновление самого Python в Sisyphus происходит дольше, чем в апстриме...
> Меня объём пересобираемых пакетов не пугает. Обновление самого Python в 
> Sisyphus происходит дольше по абсолютно другим причинам.
Не всем нравится сидеть и ждать (уже) годами, пока вы обновите Python до
следующей минорной версии, поскольку текущему образу сборки обязательно
требуется фриз сборочницы.

Перечислите все причины, которые, по вашему утверждению, затягивают
обновление.
> > Я прошу обратить внимание на эту проблему куда большую часть сообщества
> > и принять хоть какое-нибудь решение, которое не оставит все как есть.
> >
> > А под "хоть какое-нибудь решение" я имею ввиду единственное, на данный
> > момент предложенное.
> Вот из-за таких "хоть каких-нибудь решений" обновление Python и затянулось.
Да, поэтому текущее подобное решение в Sisyphus и предлагается изменить.
> > В Sisyphus сейчас есть модули с тэгом abi3 (будем надеятся, что они
> > соблюдают Stable ABI) и собранные для конкретной минорной версии
> > Python. Текущая идея сборки компилируемых модулей заключается в том,
> > чтобы везде ставить зависимость на %python3_ABI_dep. Естественно, это
> > приводит к тому, что у нас сейчас при обновлении Python мучается один
> > бедный grenka, а все сидят и смотрят на это в ожидании окончания
> > (кто-то даже успевает продлять ему муки).
> >
> > В общем, идея решения заключается в том, чтобы для модулей, собираемых
> > под Stable ABI эту зависимость не генерировать и как-нибудь проверять,
> > что там действительно Stable ABI. Для этого есть инструмент abi3audit,
> > собираемый в этом задании: https://packages.altlinux.org/tasks/396283
> Я правильно понимаю, что всё что выше написано касается всего 38 пакетов?
38 пакетов в текущий момент собраны под Stable ABI.

Это количество можно попробовать увеличить, просто передав
-DPy_LIMITED_API=0x03000000 компилятору во время сборки экстеншена.

-- 
Anton Zhukharev
ALT Linux Team

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [devel] Спасём python3 вместе! (действительно) - Stable ABI

[Anton Zhukharev]

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

On Fri, Oct 03, 2025 at 09:18:39AM +0300, Anton Zhukharev wrote:
> On Thu, Oct 02, 2025 at 10:45:34PM +0300, Grigory Ustinov wrote:
> > 02.10.2025 16:44, Anton Zhukharev пишет:
> > > Всем привет!
> > >
> > > Последние таски по обновлению Python выглядят пугающее: объем
> > > пересобираемых пакетов невероятно огромный и постоянно растет из-за чего
> > > обновление самого Python в Sisyphus происходит дольше, чем в апстриме...
> > Меня объём пересобираемых пакетов не пугает. Обновление самого Python в 
> > Sisyphus происходит дольше по абсолютно другим причинам.
> Не всем нравится сидеть и ждать (уже) годами, пока вы обновите Python до
> следующей минорной версии, поскольку текущему образу сборки обязательно
> требуется фриз сборочницы.
Извиняюсь за такую формулировку: фриз происходит на последнем этапе
сборки таска, а не на протяжении всего существования таска с обновлением
Python. 
> Перечислите все причины, которые, по вашему утверждению, затягивают
> обновление.
> > > Я прошу обратить внимание на эту проблему куда большую часть сообщества
> > > и принять хоть какое-нибудь решение, которое не оставит все как есть.
> > >
> > > А под "хоть какое-нибудь решение" я имею ввиду единственное, на данный
> > > момент предложенное.
> > Вот из-за таких "хоть каких-нибудь решений" обновление Python и затянулось.
> Да, поэтому текущее подобное решение в Sisyphus и предлагается изменить.
> > > В Sisyphus сейчас есть модули с тэгом abi3 (будем надеятся, что они
> > > соблюдают Stable ABI) и собранные для конкретной минорной версии
> > > Python. Текущая идея сборки компилируемых модулей заключается в том,
> > > чтобы везде ставить зависимость на %python3_ABI_dep. Естественно, это
> > > приводит к тому, что у нас сейчас при обновлении Python мучается один
> > > бедный grenka, а все сидят и смотрят на это в ожидании окончания
> > > (кто-то даже успевает продлять ему муки).
> > >
> > > В общем, идея решения заключается в том, чтобы для модулей, собираемых
> > > под Stable ABI эту зависимость не генерировать и как-нибудь проверять,
> > > что там действительно Stable ABI. Для этого есть инструмент abi3audit,
> > > собираемый в этом задании: https://packages.altlinux.org/tasks/396283
> > Я правильно понимаю, что всё что выше написано касается всего 38 пакетов?
> 38 пакетов в текущий момент собраны под Stable ABI.
> 
> Это количество можно попробовать увеличить, просто передав
> -DPy_LIMITED_API=0x03000000 компилятору во время сборки экстеншена.
Здесь, если что, место, которое нужно обсуждать.
Просто воткнуть 0x0300000 (то есть версию 3.0) и радоваться не
получится.

-- 
Anton Zhukharev
ALT Linux Team

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [devel] Затянувшийся фриз сборочницы

[Grigory Ustinov]

03.10.2025 9:18, Anton Zhukharev пишет:
> On Thu, Oct 02, 2025 at 10:45:34PM +0300, Grigory Ustinov wrote:
>> 02.10.2025 16:44, Anton Zhukharev пишет:
>>> Всем привет!
>>>
>>> Последние таски по обновлению Python выглядят пугающее: объем
>>> пересобираемых пакетов невероятно огромный и постоянно растет из-за чего
>>> обновление самого Python в Sisyphus происходит дольше, чем в апстриме...
>> Меня объём пересобираемых пакетов не пугает. Обновление самого Python в
>> Sisyphus происходит дольше по абсолютно другим причинам.
> Не всем нравится сидеть и ждать (уже) годами, пока вы обновите Python до
> следующей минорной версии, поскольку текущему образу сборки обязательно
> требуется фриз сборочницы.
>
> Перечислите все причины, которые, по вашему утверждению, затягивают
> обновление.

Пожалуй всё-таки имеет смысл вкратце зарезюмировать текущую ситуацию. В 
этом году фриз сборочницы действительно затянулся на неприлично 
длительное время. У всех ожидающих прошу прощения и немного понимания. Я 
жду его окончания не меньше вашего и почти в круглосуточном режиме слежу 
за таском, делая всё, что в моих силах для его скорейшего прохождения.

Сначала таск был сломан очень несвоевременным обновлением libfmt. Только 
всё разрулили, и тут с двух ног влетел Cython. Решили проблемы и с ним. 
Сейчас таск уже почти неделю в полностью готовом состоянии не может 
пройти из-за нехватки ресурсов на архитектурах i586 и aarch64. Проблема 
не в количестве пакетов, а в том, что крупные пакеты типа llvm, blender, 
vtk и тому подобные собираются вероятностно. Учитывая, что сборка идёт 
на коммит, кэширования результатов нет и имеем что имеем. 3 дня таск 
собирается, потом падает со словами
[aarch64] hasher-privd: parent: handle_io: idle time limit (3600 
seconds) exceeded

В предыдущих обновлениях python3 эта проблема была не так сильно 
выражена. Возможно имеет смысл в следующем обновлении сформировать 
список пересборки таким образом, чтобы "тяжёлые" пакеты шли поближе к 
началу, но это не всегда возможно, поскольку обычно они требуют немалые 
деревья пакетов.

Re: [devel] Затянувшийся фриз сборочницы

[Leonid Krivoshein]

Всем привет!


On 10/5/25 13:46, Grigory Ustinov wrote:
> 03.10.2025 9:18, Anton Zhukharev пишет:
>> On Thu, Oct 02, 2025 at 10:45:34PM +0300, Grigory Ustinov wrote:
>>> 02.10.2025 16:44, Anton Zhukharev пишет:
>>>> Всем привет!
>>>>
>>>> Последние таски по обновлению Python выглядят пугающее: объем
>>>> пересобираемых пакетов невероятно огромный и постоянно растет из-за 
>>>> чего
>>>> обновление самого Python в Sisyphus происходит дольше, чем в 
>>>> апстриме...
>>> Меня объём пересобираемых пакетов не пугает. Обновление самого Python в
>>> Sisyphus происходит дольше по абсолютно другим причинам.
>> Не всем нравится сидеть и ждать (уже) годами, пока вы обновите Python до
>> следующей минорной версии, поскольку текущему образу сборки обязательно
>> требуется фриз сборочницы.
>>
>> Перечислите все причины, которые, по вашему утверждению, затягивают
>> обновление.
>
> Пожалуй всё-таки имеет смысл вкратце зарезюмировать текущую ситуацию. 
> В этом году фриз сборочницы действительно затянулся на неприлично 
> длительное время.

Как я понимаю, "фриз" -- это перевод всех собираемых тасков без 
test-only в состояние POSTPONED, когда третья попытка закоммитить 
успешно собравшийся большой таск провалилась, этот "фриз" нужен для 
прохождения в репозиторий одного большого таска, верно?


> У всех ожидающих прошу прощения и немного понимания. Я жду его 
> окончания не меньше вашего и почти в круглосуточном режиме слежу за 
> таском, делая всё, что в моих силах для его скорейшего прохождения.
>
> Сначала таск был сломан очень несвоевременным обновлением libfmt. 
> Только всё разрулили, и тут с двух ног влетел Cython. Решили проблемы 
> и с ним. Сейчас таск уже почти неделю в полностью готовом состоянии не 
> может пройти из-за нехватки ресурсов на архитектурах i586 и aarch64. 
> Проблема не в количестве пакетов, а в том, что крупные пакеты типа 
> llvm, blender, vtk и тому подобные собираются вероятностно. Учитывая, 
> что сборка идёт на коммит, кэширования результатов нет и имеем что 
> имеем. 3 дня таск собирается, потом падает со словами
> [aarch64] hasher-privd: parent: handle_io: idle time limit (3600 
> seconds) exceeded
>
> В предыдущих обновлениях python3 эта проблема была не так сильно 
> выражена. Возможно имеет смысл в следующем обновлении сформировать 
> список пересборки таким образом, чтобы "тяжёлые" пакеты шли поближе к 
> началу, но это не всегда возможно, поскольку обычно они требуют 
> немалые деревья пакетов.
>

Можно внести пару усовершенствований:

1. Поменять приоритет. Он должен быть не у того таска, который *первым 
успешно собрался*, а у того, кто будучи успешно собранным *первым начал 
сборку*. Тогда будет достаточно пересобрать на новом состоянии 
репозитория менее ёмкие таски, уже успешно собравшиеся, и даже попавшие 
в архив. В этом случае их можно удалить из архива. Ёмкость таска можно 
определить по суммарному времени его сборки.

2. Разрешить создание субтасков внутри таска не с последовательной, а с 
параллельной собираемостью. Когда маинтейнеру точно известна группа 
пакетов, от которых есть зависимость, но друг на друга никакого влияния 
они не оказывают.


-- 
WBR, Leonid Krivoshein.

Re: [devel] Затянувшийся фриз сборочницы

[Anton Farygin]

On 10/5/25 13:46, Grigory Ustinov wrote:
> В предыдущих обновлениях python3 эта проблема была не так сильно 
> выражена. Возможно имеет смысл в следующем обновлении сформировать 
> список пересборки таким образом, чтобы "тяжёлые" пакеты шли поближе к 
> началу, но это не всегда возможно, поскольку обычно они требуют 
> немалые деревья пакетов.

мне кажется что без модификации сборочницы такое не обойти.

Идеально было бы иметь опцию, которая или в значительной степени 
увеличит лимиты сборочницы или заставит её самоперезапускать задание при 
падении.

Re: [devel] Затянувшийся фриз сборочницы

[Andrey Cherepanov]

05.10.2025 13:46, Grigory Ustinov пишет:
> 03.10.2025 9:18, Anton Zhukharev пишет:
>> On Thu, Oct 02, 2025 at 10:45:34PM +0300, Grigory Ustinov wrote:
>>> 02.10.2025 16:44, Anton Zhukharev пишет:
>>>> Всем привет!
>>>>
>>>> Последние таски по обновлению Python выглядят пугающее: объем
>>>> пересобираемых пакетов невероятно огромный и постоянно растет из-за 
>>>> чего
>>>> обновление самого Python в Sisyphus происходит дольше, чем в 
>>>> апстриме...
>>> Меня объём пересобираемых пакетов не пугает. Обновление самого Python в
>>> Sisyphus происходит дольше по абсолютно другим причинам.
>> Не всем нравится сидеть и ждать (уже) годами, пока вы обновите Python до
>> следующей минорной версии, поскольку текущему образу сборки обязательно
>> требуется фриз сборочницы.
>>
>> Перечислите все причины, которые, по вашему утверждению, затягивают
>> обновление.
>
> Пожалуй всё-таки имеет смысл вкратце зарезюмировать текущую ситуацию. 
> В этом году фриз сборочницы действительно затянулся на неприлично 
> длительное время. У всех ожидающих прошу прощения и немного понимания. 
> Я жду его окончания не меньше вашего и почти в круглосуточном режиме 
> слежу за таском, делая всё, что в моих силах для его скорейшего 
> прохождения.
>
> Сначала таск был сломан очень несвоевременным обновлением libfmt. 
> Только всё разрулили, и тут с двух ног влетел Cython. Решили проблемы 
> и с ним. Сейчас таск уже почти неделю в полностью готовом состоянии не 
> может пройти из-за нехватки ресурсов на архитектурах i586 и aarch64. 
> Проблема не в количестве пакетов, а в том, что крупные пакеты типа 
> llvm, blender, vtk и тому подобные собираются вероятностно. Учитывая, 
> что сборка идёт на коммит, кэширования результатов нет и имеем что 
> имеем. 3 дня таск собирается, потом падает со словами
> [aarch64] hasher-privd: parent: handle_io: idle time limit (3600 
> seconds) exceeded
>
> В предыдущих обновлениях python3 эта проблема была не так сильно 
> выражена. Возможно имеет смысл в следующем обновлении сформировать 
> список пересборки таким образом, чтобы "тяжёлые" пакеты шли поближе к 
> началу, но это не всегда возможно, поскольку обычно они требуют 
> немалые деревья пакетов.
Попроси смотрящих за сборочницей временно поднять лимиты.

-- 
Andrey Cherepanov
cas@altlinux.org

Re: [devel] Затянувшийся фриз сборочницы

[Sergey Afonin]

On Monday 06 October 2025, Andrey Cherepanov wrote:

> > началу, но это не всегда возможно, поскольку обычно они требуют 
> > немалые деревья пакетов.

> Попроси смотрящих за сборочницей временно поднять лимиты.
 
Или автоматом выставлять лимит в зависимости от пакетов. И, соответственно,
вести список тех, кто должен долго собираться. Этот список же относительно
постоянный и известный?

-- 
С уважением, Сергей Афонин.

Re: [devel] Спасём python3 вместе! (действительно) - Stable ABI

[Alexandr Shashkin]

[-- Attachment #1.1.1: Type: text/plain, Size: 7040 bytes --]

Пожалуй приурочу это письмо к выходу Python 3.14.
https://pythoninsider.blogspot.com/2025/10/python-3140-final-is-here.html

Не буду касаться сканадальной темы двух сложившихся лагерей Python
мейнтейнеров, которые соперничают друг с другом, так как не могут или
не хотят понимать интересы других и работать в команде. Сейчас не об
этом, хотя тоже играет немалую роль.

А вот о чём действительно я бы хотел высказаться, так это о том, что
текущий подход сборки каждой новой минорной версии является
экстенсивным. Если учитывать, что количество пакетов в репозитории,
которым требуется Python ABI, растёт с каждым годом, то в какой-то
момент обновление превратится в кошмар, что для мейнтейнера Python,
что для остальных мейнтейнеров Sisyphus, или станет невозможным. Уже
сейчас все таски Sisyphus висят в ожидании обновления Python, который
упорно пытается прорваться в репозиторий, но падает из-за случайных
ошибок.

Что будет дальше можно только гадать. Поэтому я считаю, что настало
время подумать о модернизации способа сборки. Если высказанное Антоном
предложение действительно позволит значительно сократить число
пересобираемых пакетов, то его стоит обязательно реализовать. Также
стоит глянуть, как новый Python попадает в репозитории других
дистрибутивов, а может даже и позаимствовать что-то. Но опять же,
делать это должен не один человек. Но для этого надо научиться
договариваться и начать действовать сообща.

On 03/10/2025 16:51, Anton Zhukharev wrote:
> On Fri, Oct 03, 2025 at 09:18:39AM +0300, Anton Zhukharev wrote:
>> On Thu, Oct 02, 2025 at 10:45:34PM +0300, Grigory Ustinov wrote:
>>> 02.10.2025 16:44, Anton Zhukharev пишет:
>>>> Всем привет!
>>>>
>>>> Последние таски по обновлению Python выглядят пугающее: объем
>>>> пересобираемых пакетов невероятно огромный и постоянно растет из-за чего
>>>> обновление самого Python в Sisyphus происходит дольше, чем в апстриме...
>>> Меня объём пересобираемых пакетов не пугает. Обновление самого Python в
>>> Sisyphus происходит дольше по абсолютно другим причинам.
>> Не всем нравится сидеть и ждать (уже) годами, пока вы обновите Python до
>> следующей минорной версии, поскольку текущему образу сборки обязательно
>> требуется фриз сборочницы.
> Извиняюсь за такую формулировку: фриз происходит на последнем этапе
> сборки таска, а не на протяжении всего существования таска с обновлением
> Python.
>> Перечислите все причины, которые, по вашему утверждению, затягивают
>> обновление.
>>>> Я прошу обратить внимание на эту проблему куда большую часть сообщества
>>>> и принять хоть какое-нибудь решение, которое не оставит все как есть.
>>>>
>>>> А под "хоть какое-нибудь решение" я имею ввиду единственное, на данный
>>>> момент предложенное.
>>> Вот из-за таких "хоть каких-нибудь решений" обновление Python и затянулось.
>> Да, поэтому текущее подобное решение в Sisyphus и предлагается изменить.
>>>> В Sisyphus сейчас есть модули с тэгом abi3 (будем надеятся, что они
>>>> соблюдают Stable ABI) и собранные для конкретной минорной версии
>>>> Python. Текущая идея сборки компилируемых модулей заключается в том,
>>>> чтобы везде ставить зависимость на %python3_ABI_dep. Естественно, это
>>>> приводит к тому, что у нас сейчас при обновлении Python мучается один
>>>> бедный grenka, а все сидят и смотрят на это в ожидании окончания
>>>> (кто-то даже успевает продлять ему муки).
>>>>
>>>> В общем, идея решения заключается в том, чтобы для модулей, собираемых
>>>> под Stable ABI эту зависимость не генерировать и как-нибудь проверять,
>>>> что там действительно Stable ABI. Для этого есть инструмент abi3audit,
>>>> собираемый в этом задании: https://packages.altlinux.org/tasks/396283
>>> Я правильно понимаю, что всё что выше написано касается всего 38 пакетов?
>> 38 пакетов в текущий момент собраны под Stable ABI.
>>
>> Это количество можно попробовать увеличить, просто передав
>> -DPy_LIMITED_API=0x03000000 компилятору во время сборки экстеншена.
> Здесь, если что, место, которое нужно обсуждать.
> Просто воткнуть 0x0300000 (то есть версию 3.0) и радоваться не
> получится.
>
>
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel

-- 
Best regards,
Alexandr Shashkin
Alt Linux Team



[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 5487 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[devel] Re: Спасём python3 вместе! (действительно) - Stable ABI

[Sergey V Turchin]

On Wednesday, 8 October 2025 15:00:46 MSK Alexandr Shashkin wrote:

[...]
> в какой-то момент обновление превратится в кошмар
А оно уже, т.к. конкретно это обновление происходит ещё с начала года, если 
правильно понимаю.

[...]

-- 
Regards, Sergey.

Re: [devel] Спасём python3 вместе! (действительно) - Stable ABI

[Anton Farygin]

On 10/8/25 15:00, Alexandr Shashkin wrote:
> что для остальных мейнтейнеров Sisyphus

Да, тут даже вопрос не в ментейнерах - некоторые пакеты с исправлением 
довольно серьёзных ошибок не могут попасть в репозиторий, пока не 
провалится python.

Для примера https://packages.altlinux.org/ru/tasks/396608/

[devel] Re: Спасём python3 вместе! (действительно) - Stable ABI

[Sergey V Turchin]

On Wednesday, 8 October 2025 15:31:50 MSK Anton Farygin wrote:
> On 10/8/25 15:00, Alexandr Shashkin wrote:
> > что для остальных мейнтейнеров Sisyphus
> 
> Да, тут даже вопрос не в ментейнерах - некоторые пакеты с исправлением
> довольно серьёзных ошибок не могут попасть в репозиторий, пока не
> провалится python.
Лично у меня уже на всё подряд наслаиваться начинает. В p11 висит таск на 
тестировании, но за время, пока его не взяли, появилось новое исправление, 
которое я не могу отправить в сизиф и, соответственно, в сборке для p11 
обновить, т.к. из очереди тестирования пропадёт, пока в сизифе последствия 
обновления python не рассосутся. И свой mkimage-profiles не могу обновить, 
т.к. новое изменение его тоже затрагивает.

[...]

-- 
Regards, Sergey.