[devel] [I] rpm-build-vm: vm-run

[Anton Farygin]

On 15.10.2019 22:06, Vladimir D. Seleznev wrote:
> On Tue, Oct 15, 2019 at 02:30:16PM +0300, Anton Farygin wrote:
>> On 15.10.2019 10:32, Michael Shigorin wrote:
>>> Зачем это тащить в hasher, особенно если на сборочнице?
>>> Собрал тестовое задание, гоняешь по нему спокойно тесты.
>> Есть цель сделать автоматическое тестирование воспроизводимым образом и
>> сразу в процессе сборки пакета.
> Если воспроизводимым образом, то прокидывать репозитории в сборочную
> среду не нужно: все требуемые пакеты нужно указать в BuildRequires.
>
> Тестирование пакетов — это безусловно важно, однако нет задачи проводить
> всеобъемлющее тестирование всевозможного поведения каждого пакета. От
> репозитория пакетов программного обеспечения в первую очередь ожидают
> других качеств: корректную доставку программного обеспечения,
> т.е. корректную установку пакетов, удаление и бесшовного обновления,
> консистентность самого репозитория. Консистентность репозитория по
> большей части у нас проверяется сборочной системой, корректность
> установки также тестируется в процессе сборки. Тестировать корректность
> обновления сложнее, и тут уже больше требуется внимательность и
> ответственность мейнтейнеров пакетов.

Тестирование консистентности установки в нашей сборочнице явно не 
покрывает тех сложных случаев, когда пакетная база обновляемой системы 
ощутимо влияет на  инструменты обновления.

Из последних примеров - это lua в p8 и mod_php5 в том же p8.

В нашем apt есть такая особенность, что если установленный в системе 
пакет требуется достаточно большому количеству установленных в системе 
пакетов - то удалить (заменить) его средствами межпакетных 
зависимостей/конфликтов практически нереально для тех случаев, когда 
Obsoletes использовать нельзя.

при этом любой пакет из уже установленных в систему может стать ошибкой 
обновления при сборке его с новой версией из конфликтующих.


Отчётливо это видно на mod_php5, который конфликтует с mod_php7 и не 
заменяется mod_php7.

Если у тебя был установлен пакет с mod_php5 в зависимостях, то даже при 
обновлении этого пакета и замене такой зависимости на mod_php7 - apt 
сообщит о конфликте и не будет продолжать работу.

Такая же проблема существует с разделяемыми библиотеками.

>
> Отдельно замечу про стабильные ветки репозитория. Стабильность означает
> неизменность общего поведения приложений. Т.е., не должно быть ситуации,
> когда в результате обновления пакета в стабильной ветке его поведение
> меняется, например, на противоположное. И стабильность невозможно в
> общем случае гарантировать обширным тестированием пакетов: довольно
> трудно формализовать неизменность поведения, в отличие от некорректного
> поведения программы. В некоторых проектах в стабильных ветках
> замораживают версии пакетов и бэкпортируют только security fixes. Это
> довольно строгое требование, особенно для прикладных программ, но
> оправданное для базовой системы. А когда, допустим, в стабильной ветке
> находится некая MyNiceDB, которая к некоторому моменту уже устарела, и
> хочется новую функциональность из новой версии (скажем, третьей), то
> лучше не обновлять эту версию, а собрать новый пакет MyNiceDB3
> (возможно, с правильным указанием конфликтов). Таким образом никому
> поведение не будет сломано, и кому надо, сможет воспользоваться новой
> версией с новой функциональностью. То же самое можно сказать и про
> разделяемые библиотеки (shared library policy в т.ч. для этого
> предлагалось).

Я не знаю дистрибутивов Linux, в которых замораживается 100% версий 
стабильного дистрибутива и идёт только бэкпорт патчей.

Хотя идея конечно, замечательная. Но тяжело реализуемая.