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

[Vladimir D. Seleznev]

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

Если воспроизводимым образом, то прокидывать репозитории в сборочную
среду не нужно: все требуемые пакеты нужно указать в BuildRequires.

Тестирование пакетов — это безусловно важно, однако нет задачи проводить
всеобъемлющее тестирование всевозможного поведения каждого пакета. От
репозитория пакетов программного обеспечения в первую очередь ожидают
других качеств: корректную доставку программного обеспечения,
т.е. корректную установку пакетов, удаление и бесшовного обновления,
консистентность самого репозитория. Консистентность репозитория по
большей части у нас проверяется сборочной системой, корректность
установки также тестируется в процессе сборки. Тестировать корректность
обновления сложнее, и тут уже больше требуется внимательность и
ответственность мейнтейнеров пакетов.

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

-- 
   С уважением,
   Владимир Селезнев