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: Wed, 16 Oct 2019 08:05:51 +0300
Message-ID: <5d39f15d-bef4-0799-2f03-357763d76ab4@basealt.ru> (raw)
In-Reply-To: <20191015190620.GA2576259@portlab>

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 
сообщит о конфликте и не будет продолжать работу.

Такая же проблема существует с разделяемыми библиотеками.

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

Я не знаю дистрибутивов Linux, в которых замораживается 100% версий 
стабильного дистрибутива и идёт только бэкпорт патчей.

Хотя идея конечно, замечательная. Но тяжело реализуемая.




  reply	other threads:[~2019-10-16  5:05 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 [this message]
2019-10-18  0:40                             ` Vladimir D. Seleznev
2019-10-18  4:48                               ` Anton Farygin
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=5d39f15d-bef4-0799-2f03-357763d76ab4@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