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

[Anton Farygin]

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.
>>>
>>> Тестирование пакетов — это безусловно важно, однако нет задачи проводить
>>> всеобъемлющее тестирование всевозможного поведения каждого пакета. От
>>> репозитория пакетов программного обеспечения в первую очередь ожидают
>>> других качеств: корректную доставку программного обеспечения,
>>> т.е. корректную установку пакетов, удаление и бесшовного обновления,
>>> консистентность самого репозитория. Консистентность репозитория по
>>> большей части у нас проверяется сборочной системой, корректность
>>> установки также тестируется в процессе сборки. Тестировать корректность
>>> обновления сложнее, и тут уже больше требуется внимательность и
>>> ответственность мейнтейнеров пакетов.
>> Тестирование консистентности установки в нашей сборочнице явно не
>> покрывает тех сложных случаев, когда пакетная база обновляемой системы
>> ощутимо влияет на  инструменты обновления.
> Поэтому я и написал по большей части, а тестирование обновляемости
> сборочницой вообще не проводится.
Именно, и в этом месте чаще всего взрывается.
>
>> Из последних примеров - это lua в p8 и mod_php5 в том же p8.
> Ровно по той же причине, что и в ответе выше.
Конечно.
>
>> В нашем apt есть такая особенность, что если установленный в системе
>> пакет требуется достаточно большому количеству установленных в системе
>> пакетов - то удалить (заменить) его средствами межпакетных
>> зависимостей/конфликтов практически нереально для тех случаев, когда
>> Obsoletes использовать нельзя.
>>
>> при этом любой пакет из уже установленных в систему может стать ошибкой
>> обновления при сборке его с новой версией из конфликтующих.
>>
>>
>> Отчётливо это видно на mod_php5, который конфликтует с mod_php7 и не
>> заменяется mod_php7.
>>
>> Если у тебя был установлен пакет с mod_php5 в зависимостях, то даже при
>> обновлении этого пакета и замене такой зависимости на mod_php7 - apt
>> сообщит о конфликте и не будет продолжать работу.
>>
>> Такая же проблема существует с разделяемыми библиотеками.
> Верно. Но это не то, для чего нужно тестировать сам apt, для этого как
> раз нужно тестирование этих пакетов на обновляемость.
>
> Тестировать apt, конечно же, нужно, но не в самом сборочном задании.

Я не вижу причин это делать не в сборочном задании. И не только apt.


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

Не 100% пакетов у нас часто замораживаются даже между стабильными 
релизами. Это не показатель.