From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: To: devel@lists.altlinux.org References: <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> <20191015190620.GA2576259@portlab> <5d39f15d-bef4-0799-2f03-357763d76ab4@basealt.ru> <20191018004029.GB170066@portlab> From: Anton Farygin X-Opacus-Archived: none Organization: BaseALT Message-ID: <2b3d1d0c-96e3-22e9-93a4-8192ff302dca@basealt.ru> Date: Fri, 18 Oct 2019 07:48:30 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <20191018004029.GB170066@portlab> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: ru 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: Fri, 18 Oct 2019 04:48:31 -0000 Archived-At: List-Archive: List-Post: 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% пакетов у нас часто замораживаются даже между стабильными релизами. Это не показатель.