Re: [devel] [SCM] packages/rpm: heads/altlinux-4.1

Re: [devel] [SCM] packages/rpm: heads/altlinux-4.1

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1427 bytes --]

On Sat, Nov 08, 2008 at 08:23:00PM +0300, Alexey M. Tourbin wrote:
> Update of /people/at/packages/rpm.git
> 
> Changes statistics since `4.0.4-alt95.M41.5-7-g43948fb' follows:
>  rpm-4_0.spec                      |    8 +++++++-
>  scripts/posttrans-filetriggers.in |   16 ++++++++--------
>  2 files changed, 15 insertions(+), 9 deletions(-)
> 
> Changelog since `4.0.4-alt95.M41.5-7-g43948fb' follows:
> commit bc50dc2a3ed5c26edc56af052b838a0a2d7b959c
> Author: Alexey Tourbin <at@altlinux>
> Date:   Sat Nov 8 19:54:44 2008 +0300
> 
>     4.0.4-alt95.M41.6
>     
>     - implemented post-transaction filetriggers, loosely based on filetriggers.patch
>       from Mandriva Linux (see %_rpmlibdir/posttrans-filetriggers for details)
>     - implemented %_rpmlibdir/0ldconfig.filetrigger, so that packages with
>       shared libraries need not invoke ldconfig(1) in they %%post-scriptlets

Ну хорошо, допустим, мы убрали вызовы %post_ldconfig/%postun_ldconfig из
spec-файлов.  Как обеспечить, чтобы в системе работал librpm с поддержкой
post-transaction filetriggers?

Как вариант, rpmbuild мог бы добавлять в пакеты зависимость типа
rpmlib(filetriggers) <= версия
при наличии в этих пакетах файлов, которые обрабатывает хотя бы один
%_rpmlibdir/*.filetrigger

Плюс зависимость типа
rpmlib-filetrigger(NAME) при наличии файлов, которые обрабатывает
%_rpmlibdir/NAME.filetrigger


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] packages/rpm: heads/altlinux-4.1

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 4280 bytes --]

On Sat, Nov 08, 2008 at 09:51:24PM +0300, Dmitry V. Levin wrote:
> On Sat, Nov 08, 2008 at 08:23:00PM +0300, Alexey M. Tourbin wrote:
> > Update of /people/at/packages/rpm.git
> > 
> > Changes statistics since `4.0.4-alt95.M41.5-7-g43948fb' follows:
> >  rpm-4_0.spec                      |    8 +++++++-
> >  scripts/posttrans-filetriggers.in |   16 ++++++++--------
> >  2 files changed, 15 insertions(+), 9 deletions(-)
> > 
> > Changelog since `4.0.4-alt95.M41.5-7-g43948fb' follows:
> > commit bc50dc2a3ed5c26edc56af052b838a0a2d7b959c
> > Author: Alexey Tourbin <at@altlinux>
> > Date:   Sat Nov 8 19:54:44 2008 +0300
> > 
> >     4.0.4-alt95.M41.6
> >     
> >     - implemented post-transaction filetriggers, loosely based on filetriggers.patch
> >       from Mandriva Linux (see %_rpmlibdir/posttrans-filetriggers for details)
> >     - implemented %_rpmlibdir/0ldconfig.filetrigger, so that packages with
> >       shared libraries need not invoke ldconfig(1) in they %%post-scriptlets
> 
> Ну хорошо, допустим, мы убрали вызовы %post_ldconfig/%postun_ldconfig из
> spec-файлов.  Как обеспечить, чтобы в системе работал librpm с поддержкой
> post-transaction filetriggers?

Выходит, что никак (по состоянию на 4.0.4-alt95.M41.5-7-g43948fb).
Самое время обсудить, как это можно сделать.

> Как вариант, rpmbuild мог бы добавлять в пакеты зависимость типа
> rpmlib(filetriggers) <= версия
> при наличии в этих пакетах файлов, которые обрабатывает хотя бы один
> %_rpmlibdir/*.filetrigger

By design файлтриггеры являются черными ящиками: в них скрыты как
критерии действия, так и выполнение самого действия.  Значит, мы не
можем определить, для данных пакетов и их файлов, будут ли выполняться
какие-либо триггеры или нет.

Это имеет смысл, потому что триггеры (как и настоящие триггеры в rpmdb)
обладают условной семантикой: _один_ пакет с триггером, если он установлен,
вызывает срабатывание действия на некоторые другие пакеты.  Для rpmdb
триггеров явно перечисляются пакеты, на которые будет срабатывать
триггер; а для файлтриггеров множество пакетов, на которых он будет
срабатывать, заранее неизвестно.

Пример, когда условное срабатывание триггера имеет смысл: пакет содержит
файл /usr/lib/menu/*.  Тогда, если установлен пакет menu, который
содержит /usr/lib/rpm/menu.filetrigger, то этот триггер будет
срабатывать.  Если же пакет menu не установлен, то триггер тоже
не установлен и срабатывать не будет.

При первой установке пакета menu нужно запустить его триггер
в %post-скрипте (потому что некоторые пакеты с /usr/lib/menu/* могут
быть уже установлены).  Это аналогично семантике %triggerin скрипта --
он будет задействован либо когда устанавливаются/обновляются пакеты
"по условию", либо когда изменяется/обновляется "сам пакет с триггером".

Нужно ли добавлять в пакет, который содержит /usr/lib/menu/*,
зависимость на menu.filegrigger?  По-моему, не нужно.

А как быть с ldconfig?  Есть ли тут аналогия с menu и %triggerin?
Вроде бы есть.  Пакет устанавливает в систему разделяему библиотеку.
В системе есть какой-то кеш разделяемых библиотек.  Пусть этот кеш
сам себя обслуживает.  Пакету с библиотекой не интересно, есть там
где-то этот кеш или нет.

Если аналогия с rpmdb триггерами верна и в привлечении этой аналогии
нет просчета, тогда можно двигаться дальше.

Почему срабатывает rpmdb триггер?  Потому что так устроена библиотека
librpm (специальной зависимости указать нельзя, но библиотека librpm
"уже давно" так устроена).  Почему должен сработать
/usr/lib/rpm/menu.filetrigger?  Потому что этот скрипт должен (косвенно)
запуститься из librpm.  Но если в системе установлена старая версия
librpm, то она его не запустит.

Получается, что зависимость вида rpmlib(filetriggers) нужна в пакетах
*с триггерами*, чтобы триггеры гарантированно запускались.

> Плюс зависимость типа
> rpmlib-filetrigger(NAME) при наличии файлов, которые обрабатывает
> %_rpmlibdir/NAME.filetrigger

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

ldconfig тут является слишком неудачным частным случаем: нельзя, чтобы
пакет rpm зависел (через 0ldconfig.filetrigger) от rpmlib(filetriggers).
Иначе такой пакет rpm будет очень трудно установить.

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] packages/rpm: heads/altlinux-4.1

[Alexey Tourbin]

[-- Attachment #1: Type: text/plain, Size: 3115 bytes --]

On Sat, Nov 08, 2008 at 10:32:40PM +0300, Alexey Tourbin wrote:
> By design файлтриггеры являются черными ящиками: в них скрыты как
> критерии действия, так и выполнение самого действия.  Значит, мы не
> можем определить, для данных пакетов и их файлов, будут ли выполняться
> какие-либо триггеры или нет.
> 
> Это имеет смысл, потому что триггеры (как и настоящие триггеры в rpmdb)
> обладают условной семантикой: _один_ пакет с триггером, если он установлен,
> вызывает срабатывание действия на некоторые другие пакеты.  Для rpmdb
> триггеров явно перечисляются пакеты, на которые будет срабатывать
> триггер; а для файлтриггеров множество пакетов, на которых он будет
> срабатывать, заранее неизвестно.
>
> Пример, когда условное срабатывание триггера имеет смысл: пакет содержит
> файл /usr/lib/menu/*.  Тогда, если установлен пакет menu, который
> содержит /usr/lib/rpm/menu.filetrigger, то этот триггер будет
> срабатывать.  Если же пакет menu не установлен, то триггер тоже
> не установлен и срабатывать не будет.
> 
> При первой установке пакета menu нужно запустить его триггер
> в %post-скрипте (потому что некоторые пакеты с /usr/lib/menu/* могут
> быть уже установлены).  Это аналогично семантике %triggerin скрипта --
> он будет задействован либо когда устанавливаются/обновляются пакеты
> "по условию", либо когда изменяется/обновляется "сам пакет с триггером".
> 
> Нужно ли добавлять в пакет, который содержит /usr/lib/menu/*,
> зависимость на menu.filegrigger?  По-моему, не нужно.

Всё равно получается разрыв.  Пусть были пакеты a, b, c, ... которые
вызывали в %post-скриптах update-foo.  Теперь в новой версии пакета foo
мы сделали foo.filetrigger, а из пакетов a, b, c, ... стали убирать
вызов update-foo.

Чтобы надёжно ликвидировать разрыв, нужна такая логика проставления
зависимостей:

	if условие foo триггера выполнено для данного пакета; then
		if grep update-foo %post-скрипт; then
			: пакет сам вызывает update-foo
		elif зависимость на foo обязательная; then
			Requires foo-with-filetrigger
		elif зависимость на foo условная; then
			Conflicts foo-without-filetrigger
		fi
	fi

> А как быть с ldconfig?  Есть ли тут аналогия с menu и %triggerin?
> Вроде бы есть.  Пакет устанавливает в систему разделяему библиотеку.
> В системе есть какой-то кеш разделяемых библиотек.  Пусть этот кеш
> сам себя обслуживает.  Пакету с библиотекой не интересно, есть там
> где-то этот кеш или нет.
> 
> Если аналогия с rpmdb триггерами верна и в привлечении этой аналогии
> нет просчета, тогда можно двигаться дальше.
> 
> Почему срабатывает rpmdb триггер?  Потому что так устроена библиотека
> librpm (специальной зависимости указать нельзя, но библиотека librpm
> "уже давно" так устроена).  Почему должен сработать
> /usr/lib/rpm/menu.filetrigger?  Потому что этот скрипт должен (косвенно)
> запуститься из librpm.  Но если в системе установлена старая версия
> librpm, то она его не запустит.
> 
> Получается, что зависимость вида rpmlib(filetriggers) нужна в пакетах
> *с триггерами*, чтобы триггеры гарантированно запускались.

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]