ALT Linux Team development discussions
 help / color / mirror / Atom feed
From: Anton Farygin <rider@basealt.ru>
To: devel@lists.altlinux.org
Subject: Re: [devel] [I] rpm-build-vm: vm-run
Date: Fri, 18 Oct 2019 07:48:30 +0300
Message-ID: <2b3d1d0c-96e3-22e9-93a4-8192ff302dca@basealt.ru> (raw)
In-Reply-To: <20191018004029.GB170066@portlab>

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% пакетов у нас часто замораживаются даже между стабильными 
релизами. Это не показатель.




  reply	other threads:[~2019-10-18  4:48 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-13 21:29 Vitaly Chikunov
2019-10-14  6:18 ` Anton Farygin
2019-10-14 11:16   ` Vitaly Chikunov
2019-10-14 11:25     ` Anton Farygin
2019-10-14 12:22       ` Vitaly Chikunov
2019-10-14 12:33         ` Anton Farygin
2019-10-14 12:36           ` Alexey V. Vissarionov
2019-10-14 12:39           ` Vitaly Chikunov
2019-10-14 12:42             ` Alexey V. Vissarionov
2019-10-14 20:54           ` Dmitry V. Levin
2019-10-14 21:53             ` Vladimir D. Seleznev
2019-10-15  3:56               ` Anton Farygin
2019-10-15  6:19                 ` Vladimir D. Seleznev
2019-10-15  7:05                   ` Anton Farygin
2019-10-15  7:17                     ` Alexey V. Vissarionov
2019-10-15 11:31                       ` Anton Farygin
2019-10-15  7:32                     ` Michael Shigorin
2019-10-15 11:30                       ` Anton Farygin
2019-10-15 18:22                         ` Dmitry V. Levin
2019-10-15 18:28                           ` Anton Farygin
2019-10-15 18:33                             ` Dmitry V. Levin
2019-10-15 18:48                               ` Anton Farygin
2019-10-15 19:08                                 ` Vladimir D. Seleznev
2019-10-16  4:48                                   ` Anton Farygin
2019-10-16  4:51                                     ` Alexey V. Vissarionov
2019-10-15 19:24                                 ` Dmitry V. Levin
2019-10-15 19:44                                   ` Vitaly Chikunov
2019-10-16  4:52                                     ` Anton Farygin
2019-10-15 22:33                                   ` Alexey V. Vissarionov
2019-10-16  4:56                                   ` Anton Farygin
2019-10-15 19:06                         ` Vladimir D. Seleznev
2019-10-16  5:05                           ` Anton Farygin
2019-10-18  0:40                             ` Vladimir D. Seleznev
2019-10-18  4:48                               ` Anton Farygin [this message]
2019-10-18 17:43                                 ` Vladimir D. Seleznev
2019-10-19  5:16                                   ` Anton Farygin
2019-10-18  8:32                               ` Michael Shigorin
2019-10-18  9:12                                 ` Anton Farygin
2019-10-18  9:29                                   ` Michael Shigorin
2019-10-18  9:36                                     ` Anton Farygin
2019-10-18 10:39                                       ` [devel] [JT] сборочница 3.0, qa/ci, ресурсы, приоритеты (was: [I] rpm-build-vm: vm-run) Michael Shigorin
2019-10-18 10:52                                         ` [devel] [JT] сборочница 3.0, qa/ci, ресурсы, приоритеты Anton Farygin
2019-10-15  4:04             ` [devel] [I] rpm-build-vm: vm-run Anton Farygin
2019-10-15  4:16               ` Alexey V. Vissarionov
2019-10-15  5:22                 ` Anton Farygin
2019-10-15  5:25                   ` Alexey V. Vissarionov
2019-12-11 11:15 ` Anton Farygin
2019-12-11 12:33   ` Vitaly Chikunov
2019-12-11 16:48     ` Anton Farygin
2019-12-12 15:12       ` Anton Farygin
2019-12-12 16:06         ` Vitaly Chikunov
2019-12-12 16:25           ` Anton Farygin
2019-12-16  4:04           ` Anton Farygin
2019-12-12 16:21 ` [devel] [I] rpm-build-vm: vm-run (update 1.3) Vitaly Chikunov
2020-02-18  7:56 ` [devel] [I] rpm-build-vm: vm-run Oleg Solovyov
2020-02-18 10:32   ` Vitaly Chikunov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2b3d1d0c-96e3-22e9-93a4-8192ff302dca@basealt.ru \
    --to=rider@basealt.ru \
    --cc=devel@lists.altlinux.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

ALT Linux Team development discussions

This inbox may be cloned and mirrored by anyone:

	git clone --mirror http://lore.altlinux.org/devel/0 devel/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 devel devel/ http://lore.altlinux.org/devel \
		devel@altlinux.org devel@altlinux.ru devel@lists.altlinux.org devel@lists.altlinux.ru devel@linux.iplabs.ru mandrake-russian@linuxteam.iplabs.ru sisyphus@linuxteam.iplabs.ru
	public-inbox-index devel

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://lore.altlinux.org/org.altlinux.lists.devel


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git