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

[Anton Farygin]

On 18.10.2019 20:43, Vladimir D. Seleznev wrote:
> On Fri, Oct 18, 2019 at 07:48:30AM +0300, Anton Farygin wrote:
>> On 18.10.2019 3:40, Vladimir D. Seleznev wrote:
>>> 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.
>>>>>
>>>>> Тестирование пакетов — это безусловно важно, однако нет задачи проводить
>>>>> всеобъемлющее тестирование всевозможного поведения каждого пакета. От
>>>>> репозитория пакетов программного обеспечения в первую очередь ожидают
>>>>> других качеств: корректную доставку программного обеспечения,
>>>>> т.е. корректную установку пакетов, удаление и бесшовного обновления,
>>>>> консистентность самого репозитория. Консистентность репозитория по
>>>>> большей части у нас проверяется сборочной системой, корректность
>>>>> установки также тестируется в процессе сборки. Тестировать корректность
>>>>> обновления сложнее, и тут уже больше требуется внимательность и
>>>>> ответственность мейнтейнеров пакетов.
>>>> Тестирование консистентности установки в нашей сборочнице явно не
>>>> покрывает тех сложных случаев, когда пакетная база обновляемой системы
>>>> ощутимо влияет на  инструменты обновления.
>>> Поэтому я и написал по большей части, а тестирование обновляемости
>>> сборочницой вообще не проводится.
>> Именно, и в этом месте чаще всего взрывается.
> Я не спорю, наоборот: я изначально написал, что именно это и надо лучше
> тестировать. Но это не задача сборочницы. Более того, практически
> невозможно формализовать автоматическое тестирование такого на стороне
> сборочницы.
Почему ? Очень даже хорошо формализуется.
>
>>> [...]
>>> Тестировать apt, конечно же, нужно, но не в самом сборочном задании.
>> Я не вижу причин это делать не в сборочном задании. И не только apt.
> Сборочница для этого не предназначена.
Ну это же не проблема.
>
>>>>> [...]
>>>> Я не знаю дистрибутивов Linux, в которых замораживается 100% версий
>>>> стабильного дистрибутива и идёт только бэкпорт патчей.
>>> Вроде бы по крайней мере раньше Debian делал очень близкое к этому, но
>>> опять-таки, я не говорю про 100% пакетов.
>> Не 100% пакетов у нас часто замораживаются даже между стабильными
>> релизами. Это не показатель.
> Эти "не 100% пакетов" — о-малое, не надо переиначивать мою мысль. Если
> называете бранчи стабильными, то нужно, чтобы они были стабильными.
Тогда надо начинать с описания формулы стабильности бранча. Т.е. - каких 
целей мы хотим достигнуть в "стабильности" ?