Re: [devel] баланс интересов (was: I: регулярные сборки тулчейна, изменение в сопровождении пакетов)

[Andrey Savchenko <bircoph@altlinux.org>]

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

On Mon, 5 Apr 2021 17:42:41 +0300 Andrey Cherepanov wrote:
> 05.04.2021 17:31, Andrey Savchenko пишет:
> > On Mon, 5 Apr 2021 09:28:14 +0300 Andrey Cherepanov wrote:
> >> 05.04.2021 08:23, Grigory Ustinov пишет:
> > [...]
> >>> Мейнтейнеров много хороших и разных. Некоторые поддерживают десяток
> >>> пакетов, некоторые сотню, а некоторые тысячу, а срок исправления для
> >>> всех одинаковый. Есть у нас и такие мейнтейнеры, которые в текстовом
> >>> файле есть, а по факту их нет.
> >>>
> >>> Лично моё мнение, что удаление ftbfs через месяц приведёт к огромному
> >>> количеству проблем, начиная с мощного уменьшения пакетной базы и
> >>> заканчивая уменьшением количества мейнтейнеров из коммьюнити.
> >> Даже если все пакеты из FTBFS будут удалены, не порождая анметов, это не
> >> превысит 1%.
> > Но ведь породят, и их зависимости породят. В итоге будет развесистый
> > граф и где-нибудь за год половина репозитория будет вынесена, вместе
> > с половиной мейнтенеров.
> Если задание на удаление из-за анметов не будет выполнено, это повод 
> исправить пакет. Не надо драматизировать ситуацию и призывать к 
> тотальному удалению всех непересобираемых пакетов. Задача, как я 
> понимаю, избавиться от откровенно ненужных и непересобираемых пакетов. 

Проблема в том, что нет единого критерия нужности. В своё время
решили, что HPC нам не нужен: в итоге грохнули torque, slurm, hpl,
зарезали на уровне сборочницы саму возможность использования
альтернативных реализаций blas и lapack; openmpi откровенно на
ладан дышит. В общем, убита вся экосистема ради теоретических благ.

> >> Социальная сторона также некритична: если мейнтейнер не чинил пакет, то
> >> и реакции на удаление вряд ли стоит ждать.
> > Не согласен. С социальной точки зрения критически важно то, как
> > мейнтенеры ощущают отношение к себе, особенно когда речь
> > о добровольцах, а не о сотрудниках на зарплате.
> >
> > Вот пример реакции: они сломали мой пакет (новая «дурацкая» проверка
> > в сборочнице, новая версия используемой библиотеки с разломанным
> > API, новый глючный тулчейн, новая среда сборочницы с посыпавшимися
> > системными вызовами, проблема только на редкой архитектуре и т.д.
> > и т.п.), не дали времени на исправление (FTBFS в месяц) или не дали
> > возможности для отладки (не у всех мейнтенеров есть доступ ко всем
> > архитектурам, qemu не всегда вариант; специфические для beehive
> > ошибки тоже простым смертным не отладить) и просто выносят — ну
> > и в баню это всё куда подальше.
> >
> > Честно, подобные эмоции порой возникают на фоне постоянного
> > закручивания гаек ради не совсем понятно чего.
> Есть статистика?

Статистика чего? Личных эмоций? Или того, как люди уходили из тима
за всю его историю? Первую я не собираю. Вторую можно пособирать
у старожилов, но точно определить причины ухода человека в общем
случае сложно.

> > У нас есть некоторый перекос: для мейнтенеров одних библиотек
> > (и в целом пакетов) есть требование чинить всё, что сломало их
> > обновление; для мейнтенеров других всё наоборот и они требуют
> > чинить всех остальных всё то, что сломали их обновления. По-моему,
> > здесь не хватает справедливого policy.
> Кто напишет?

Прежде чем писать, нужно обсудить что сообщество считает разумным.

Будет ли разумным требовать даунстримы (т.е. мейнтенеров зависимых
пакетов) исправлять все проблемы, вызванные обновлением
зависимости, если речь идёт не про ошибку в арстримном пакете,
а про изменение API и т.п.?

Мне представляется, что для тяжёлых пакетов — т.е. для того, что
тянет за собой большой граф зависимостей — целесообразно проводить
тестирование перед реальным обновлением. И здесь мы упираемся
в очередную проблему нашей чудо-сборочницы: в общем случае нельзя
взять и построить полный граф сборочных зависимостей.

> >> А вернуть удалённые при желании очень просто.
> > На самом деле не всегда, например, когда вынесли следом половину
> > нужных зависимостей или разломали фичи оставшихся.
> 
> Примеры?

Любая сложная экосистема. Выше описан пример HPC: системы
управления заданиями у нас вырезаны на корню, возможности
переключения альтернатив стандартных вычислительных библиотек
сведены к почти нулю — а в мире HPC это очень востребовано!

В итоге нет возможности полноценно собрать и обновить openmpi.
Не говоря о том, что альтеранативные реализации MPI — ну тот же
mpich2 тоже вырезаны и добавить их будет очень тяжело. Ага, снова
пресловутые duplicate provides.

Как результат, возможность сборки вычислительного научного софта
в Альте существенно ограничена целым клубком проблем и «легко взять
и вернуть» отдельный пакет уже невозможно, т.к. утеряна экосистема.
Ну lammps, например.

Аналогичные проблемы могут быть и с другими экосистемами. Например,
у нас раздавались предложения удалить ruby из репозитория и были
массово удалены зависимости из ряда пакетов — _если_ это будет
полностью осуществлено, последствия будут катастрофическими
и просто взять и вернуть, скажем тот же mkvtoolnix будет уже
невозможно.

Есть и зависшая в воздухе проблема с TeXLive: экосистема сложная,
сборочница оказалась технически неспособна обработать её сборку.
Но ответственные лица решили, что так и должно быть.  В итоге
собрано костыльным способом, чтоб было хоть что-то, что,
безусловно, тоже ограничивает возможность использования и развития
экосистемы.

Best regards,
Andrew Savchenko

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