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

[Vladimir D. Seleznev]

On Wed, Oct 16, 2019 at 08:05:51AM +0300, Anton Farygin wrote:
> 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 
> сообщит о конфликте и не будет продолжать работу.
> 
> Такая же проблема существует с разделяемыми библиотеками.

Верно. Но это не то, для чего нужно тестировать сам apt, для этого как
раз нужно тестирование этих пакетов на обновляемость.

Тестировать apt, конечно же, нужно, но не в самом сборочном задании.

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

Вроде бы по крайней мере раньше Debian делал очень близкое к этому, но
опять-таки, я не говорю про 100% пакетов.

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

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