Re: [devel] I: glibc 2.32 && sisyphus snapshot publication skip

[Alexey Tourbin <alexey.tourbin@gmail.com>]

On Mon, Dec 21, 2020 at 2:34 PM Dmitry V. Levin <ldv@altlinux.org> wrote:
> > Если бы при
> > сборке openssh выполнялся полноценный тест (запустить sshd на высоком
> > порту и попробовать к нему подключиться), то пакет перестал бы
> > пересобираться. Но что-то не видно, чтобы в openssh.spec выполнялись
> > какие-нибудь тесты.
>
> Для начала мы планируем доделать make check в openssh, там есть некоторые
> заморочки с переносом тестов в qemu.
>
> Далее есть выбор из двух вариантов:
> - Запаковать openssh-checkinstall, а также glibc-checkinstall,
>   openssl-checkinstall, и т.д., добавив в них зависимости
>   на openssh-checkinstall.
> - Пересобирать openssh при каждом значимом изменении пакетов (если
>   меняется rpm identity), входящих в его сборочную среду, с публикацией
>   результата пересборки, если он меняется значимым образом (если меняется
>   rpm identity).

Второй вариант слишком радикальный. Он кагбе дезавуирует понятие
бинарной совместимости как подозрительное. Возможен даже более
радикальный вариант: намертво приклеиваться к версиям библиотек, от
которых зависит сборка (openssh-server будет требовать glibc-core =
%version-%release). Этим мы кагбе говорим: в такой комбинации точно
работало; будет ли работать в других комбинациях - бог весть, надо
пересобрать, чтобы убедиться. Конечно, с rpm такой трюк не пройдет,
потому что в системе может быть установлен только один glibc-core.
По-моему, Nix package manager реализует как раз такую идею: он клеет
намертво и умеет бесконфликтно устанавливать намертво приклеенные
библиотеки.

Я посмотрел, как устроены пакеты checkinstall. Немного странно, что
они складывают программы в /var и запускают их в %post. Но может так и
лучше (для запуска тестов не требуется entry point).

Как тогда это может работать? В репозитории есть несколько десятков
пакетов *-checkinstall. Для каждого из них сборочная система
поддерживает список пакетов в чруте. Отдельная стадия сборки задания -
вычисление списков для *-checkinstall. Следующая стадия - для тех
*-checkinstall пакетов, у которых меняется содержимое чрута,
выполняется дополнительный install test (устанавливается именно этот
foo-checkinstall пакет).

В общем, это дополнительная работа по поддержке checkinstall пакетов.
Они не обязательно должны полностью реплицировать 'make check': 'make
check' может выполняться долго, а foo-checkinstall желательно чтобы
устанавливался достаточно быстро.

Другое направление мысли - надо поднимать в чруте настоящий сервис
sshd.  На современных ядрах это можно делать без прав рута, через
kernel.unprivileged_userns_clone=1. Плюс в том, что этим проверяется
боевая конфигурация. Минус в том, что такие контейнеры разворачиваются
дольше, и готового минималистичного решения для этого скорее всего
нет. Еще одно направление мысли - надо тестировать обновление rpm -U,
а не установку rpm -i, и проверять, что sshd перезапустился, после
чего пробовать к нему подключиться.

* * *

А почему вообще в репозитории openssh старой версии - 7.9? В Федоре 33
версия 8.4.

Мужчина, вы не так давно писали, что у пакетов должен быть мейнтейнер,
а если мейнтейнера нету, то не надо такие суррогатные пакеты
направлять в основной репозиторий и т.п. Между тем, если бы робот
синхронизировал сборку openssh с Федорой, а в релисе у этой сборки был
знак подчеркивания, то дефекта с seccomp просто не возникло бы.

В ваших рассуждениях про мейнтейнеров есть bias: поскольку вы
стейкхолдер, то вы исходите из того, как должен быть устроен проект в
целом, какие у него цели и задачи, что суть правильно в отвлеченном
смысле и т.п.  К этому еще примешиваются конъюнктурные соображение:
дескать "мы же не дериватив", поэтому надо как-то сигналить городу и
миру, что мы автохтонная Русская ОС для ЭВМ и т.п.

Bias становится ясен, если принять более прагматичный взгляд конечно
пользователя. Многих пользователей Русской ОС заставляют ею
пользоваться, спуская ее сверху (в бюджетных организациях и т.п.). То
есть многие пользователи - не стейкхолдеры, им всё равно, как устроен
проект, есть ли у пакетов мейнтейнеры и т.п. Им только нужно, чтобы
всё работало - не хуже, чем в других дистрибутивах. Если в
дистрибутиве есть "импортозамещённые баги", то это ужасный bummer.
Если же баги такие как у всех, то bummer не такой ужасный.

Это приводит меня к мысли, что нужно активнее синхронизировать всю
пакетную базу с апстримом и с другими дистрибутивами. Если дистрибутив
отходит от типичного сочетания версий (openssh и glibc), то он берет
на себя дополнительные риски, и, хуже того, перекладывает их на
конечных пользователей.