From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Tue, 15 Oct 2019 22:06:20 +0300 From: "Vladimir D. Seleznev" To: ALT Linux Team development discussions Message-ID: <20191015190620.GA2576259@portlab> References: <9eec954f-2ae9-0c99-90cb-680b2ae81c12@basealt.ru> <20191014122241.dzsitliu75mb6xdw@altlinux.org> <20191014205429.GB4322@altlinux.org> <20191014215312.GA1422683@portlab> <389be035-2465-8c54-5cb3-93eadbc94267@basealt.ru> <20191015061954.GA2061077@portlab> <20191015073206.GH18867@imap.altlinux.org> <194fdb47-10a6-42d1-467c-f6ddd77b6638@basealt.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <194fdb47-10a6-42d1-467c-f6ddd77b6638@basealt.ru> User-Agent: Mutt/1.10.1 (2018-07-13) Subject: Re: [devel] [I] rpm-build-vm: vm-run X-BeenThere: devel@lists.altlinux.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ALT Linux Team development discussions List-Id: ALT Linux Team development discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2019 19:06:21 -0000 Archived-At: List-Archive: List-Post: 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 в т.ч. для этого предлагалось). -- С уважением, Владимир Селезнев