[devel] posttrans filetriggers [2]

[devel] posttrans filetriggers [2]

[Alexey Tourbin]

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

Юрий Седунов просил меня реализовать posttrans filetriggers,
чтобы решить проблему c gtk icon cache в branch-4.1 (для предостящего
релиза дистрибутива).

Проблема это такая: библиотека libgtk+2 может использовать кеш
иконок /usr/share/icons/hicolor/icon-theme.cache, чтобы ускорить
загрузку иконок.  По умолчанию этот кеш отсутствует; но если он создан,
то libgtk+2 не находит иконки, отсутствующие в кеше (но существующие в
файловой системе).

Пакет NetworkManager-gnome создаёт/обновляет этот кеш, а большая часть
других пакетов (около 700+ штук) не создаёт и не обновляет этот кеш.  Это
означает, что после установки NetworkManager-gnome библиотека libgtk+2
будет использовать кеш, созданный на стадии установки NetworkManager-gnome,
а установка дополнительных пакетов с иконками на этот кеш никак не
повлияет, то есть, в конечном счёте, в приложениях будут битые иконки.

Возможное решение проблемы -- добавить %post-скрипт для обновления кеша
иконок во все пакеты, которые содержат /usr/share/icons/hicolor/*.
Возражения:
1) Пачить 700+ штук пакетов -- мартышкин труд.
2) Пакеты с иконками не обязаны знать специфику работы libgtk+2 кеша,
и даже что он вообще есть.
3) Можно сэкономить время на установке, если создать/обновить кеш
только один раз, в конце транзакции.

Идея posttrans filetriggers простая -- во время выполнения транзакции
создаётся список установленных/удалённых файлов.  Дальше можно написать
скрипт, который, если транзакция успешно завершилась, получит на вход
этот список файлов и сможет выполнить определённые действия.

Упрощенный пример для обновления кеша иконок.

/usr/lib/rpm/gtk+2-icon-cache.filetrigger:
	#!/bin/sh
	if grep -qs ^/usr/share/icons/hicolor/; then
		gtk-update-icon-cache --force --ignore-theme-index
	fi

Упрощенный пример для регистрации GConf2 схем.

/usr/lib/rpm/GConf2-schemas.filetrigger:
	#!/bin/sh
	install=
	remove=
	while read -r f; do
		case "$f" in
			/etc/gconf/schemas/*.schemas) ;;
			*) continue ;;
		esac
		if [ -f "$f" ]; then
			install="$install $f"
		else
			remove="$remove $f"
		fi
	done
	[ -z "$install" ] || gconftool-2 --makefile-install-rule $install
	[ -z "$remove" ] || gconftool-2 --makefile-uninstall-rule $remove

Последний пример показывает, что можно реализовать достаточно сложные
случаи обработки аргументов, накапливая аргументы в цикле (чтобы
запустить прогрмму всего одни раз).  На самом деле в реальном скрипте
лучше использовать xargs --delimiter='\n', потому что argv может
переполниться, а файлы могут содержать пробелы).

В отличие от мандривовского патча, я не стал делать у файлов префиксы
"+" и "-", т.к. из-за особенностей librpm нельзя сделать чтобы это
хорошо работало (т.е. "+" может и не означать, что файл был добавлен,
а "-" может не означать, что файл таки был удалён).  В последнем примере
я просто явно проверяю [ -f "$f" ].

Changelog since common ancestor `4.0.4-alt95.M41.2' follows:
commit 462bd2a2b95b6946ccd347b8d1848943d5ae3c99
Author: Alexey Tourbin <at@altlinux>
Date:   Mon Sep 8 10:57:19 2008 +0400

    implemented posttrans filetriggers, vaguely based on Mandriva patch

Full diff since common ancestor `4.0.4-alt95.M41.2' follows:
diff --git a/a b/a
new file mode 100644
index 0000000..e69de29
diff --git a/configure.in b/configure.in
index 2e7b53e..82a959c 100644
--- a/configure.in
+++ b/configure.in
@@ -1022,6 +1022,7 @@ AC_OUTPUT([ Doxyfile Makefile rpmrc macros platform rpmpopt rpm.spec
 	scripts/strip_files
 	scripts/symlinks.req
 	scripts/verify-elf
+	scripts/posttrans-filetriggers
 	tests/Makefile tests/rpmrc tests/macros tests/hello-test/Makefile
 	po/Makefile.in
 	doc/Makefile doc/manual/Makefile
diff --git a/lib/psm.c b/lib/psm.c
index b9e6f8e..3ccaf60 100644
--- a/lib/psm.c
+++ b/lib/psm.c
@@ -900,7 +900,7 @@ static int runScript(PSM_t psm, Header h,
     int freePrefixes = 0;
     FD_t out;
     rpmRC rc = RPMRC_OK;
-    const char *n, *v, *r;
+    const char *n = NULL, *v = NULL, *r = NULL;
     char arg1_str [sizeof(int)*3+1] = "";
     char arg2_str [sizeof(int)*3+1] = "";
 
@@ -917,6 +917,7 @@ static int runScript(PSM_t psm, Header h,
 	argc = progArgc;
     }
 
+    if (h)
     xx = headerNVR(h, &n, &v, &r);
 
     if (arg1 >= 0)
@@ -924,9 +925,9 @@ static int runScript(PSM_t psm, Header h,
     if (arg2 >= 0)
 	sprintf(arg2_str, "%d", arg2);
 
-    if (hge(h, RPMTAG_INSTPREFIXES, &ipt, (void **) &prefixes, &numPrefixes)) {
+    if (h && hge(h, RPMTAG_INSTPREFIXES, &ipt, (void **) &prefixes, &numPrefixes)) {
 	freePrefixes = 1;
-    } else if (hge(h, RPMTAG_INSTALLPREFIX, NULL, (void **) &oldPrefix, NULL)) {
+    } else if (h && hge(h, RPMTAG_INSTALLPREFIX, NULL, (void **) &oldPrefix, NULL)) {
 	prefixes = &oldPrefix;
 	numPrefixes = 1;
     } else {
@@ -1038,6 +1039,7 @@ static int runScript(PSM_t psm, Header h,
 	    }
 	}
 
+	if (n)
 	dosetenv ("RPM_INSTALL_NAME", n, 1);
 
 	if (*arg1_str)
@@ -2130,3 +2132,58 @@ fprintf(stderr, "*** PSM_RDB_LOAD: header #%u not found\n", fi->record);
     return rc;
     /*@=nullstate@*/
 }
+
+static
+void saveTriggerFiles(PSM_t psm)
+{
+    const rpmTransactionSet ts = psm->ts;
+    if (ts->transFlags & RPMTRANS_FLAG_TEST)
+	return;
+    if (ts->transFlags & (_noTransScripts | _noTransTriggers))
+	return;
+    const TFI_t fi = psm->fi;
+    if (fi->fc < 1)
+	return;
+    psmStage(psm, PSM_CHROOT_IN);
+    const char *file = rpmGetPath(ts->rpmdb->db_home, "/files-awaiting-filetriggers");
+    FILE *fp = fopen(file, "a");
+    if (fp == NULL)
+	rpmError(RPMERR_OPEN, "open of %s failed: %s\n", file, strerror(errno));
+    else {
+	int i;
+	for (i = 0; i < fi->fc; i++)
+	    fprintf(fp, "%s%s\n", fi->dnl[fi->dil[i]], fi->bnl[i]);
+	fclose(fp);
+    }
+    file = _free(file);
+    psmStage(psm, PSM_CHROOT_OUT);
+}
+
+void psmTriggerAdded(PSM_t psm)
+{
+    saveTriggerFiles(psm);
+}
+
+void psmTriggerRemoved(PSM_t psm)
+{
+    saveTriggerFiles(psm);
+}
+
+void psmTriggerPosttrans(PSM_t psm)
+{
+    const rpmTransactionSet ts = psm->ts;
+    if (ts->transFlags & RPMTRANS_FLAG_TEST)
+	return;
+    if (ts->transFlags & (_noTransScripts | _noTransTriggers))
+	return;
+    psmStage(psm, PSM_CHROOT_IN);
+    const char *file = rpmGetPath(ts->rpmdb->db_home, "/files-awaiting-filetriggers");
+    const char *script = RPMCONFIGDIR "/posttrans-filetriggers";
+    const char *argv[] = { script, file, NULL };
+    rpmMessage(RPMMESS_VERBOSE, _("Running %s\n"), script);
+    int rc = runScript(psm, NULL, script, 2, argv, NULL, 0, 0);
+    if (rc == 0)
+	unlink(file);
+    file = _free(file);
+    psmStage(psm, PSM_CHROOT_OUT);
+}
diff --git a/lib/psm.h b/lib/psm.h
index 968178b..90f1419 100644
--- a/lib/psm.h
+++ b/lib/psm.h
@@ -233,6 +233,11 @@ int psmStage(PSM_t psm, pkgStage stage)
 	/*@modifies psm, rpmGlobalMacroContext,
 		fileSystem, internalState @*/;
 
+/* ALT: hack to implement file triggers */
+void psmTriggerAdded(PSM_t psm);
+void psmTriggerRemoved(PSM_t psm);
+void psmTriggerPosttrans(PSM_t psm);
+
 #ifdef __cplusplus
 }
 #endif
diff --git a/lib/transaction.c b/lib/transaction.c
index 2073882..ade1c46 100644
--- a/lib/transaction.c
+++ b/lib/transaction.c
@@ -2068,6 +2068,9 @@ assert(alp == fi->ap);
 		    ourrc++;
 		    lastFailed = i;
 		}
+		else {
+		    psmTriggerAdded(psm);
+		}
 		fi->h = headerFree(fi->h);
 		if (hsave) {
 		    fi->h = headerLink(hsave);
@@ -2094,11 +2097,18 @@ assert(alp == fi->ap);
 
 	    if (psmStage(psm, PSM_PKGERASE))
 		ourrc++;
+	    else {
+		psmTriggerRemoved(psm);
+	    }
 
 	    break;
 	}
 	(void) rpmdbSync(ts->rpmdb);
     }
+
+    if (ourrc == 0)
+	psmTriggerPosttrans(psm);
+
     tsi = tsFreeIterator(tsi);
 
     ts->flList = freeFl(ts, ts->flList);
diff --git a/rpm-4_0.spec b/rpm-4_0.spec
index 46c08b8..435831f 100644
--- a/rpm-4_0.spec
+++ b/rpm-4_0.spec
@@ -291,6 +291,7 @@ for dbi in \
 do
     touch "%buildroot%_localstatedir/%name/$dbi"
 done
+touch %buildroot%_localstatedir/%name/files-awaiting-filetriggers
 
 # Prepare documentation.
 bzip2 -9 CHANGES ||:
@@ -444,6 +445,7 @@ fi
 %rpmdbattr %_localstatedir/%name/Sigmd5
 %rpmdbattr %_localstatedir/%name/Sha1header
 %rpmdbattr %_localstatedir/%name/Triggername
+%rpmdbattr %_localstatedir/%name/files-awaiting-filetriggers
 
 /bin/rpm
 %_bindir/rpm
@@ -465,6 +467,8 @@ fi
 %_prefix/lib/rpmpopt
 %_prefix/lib/rpmrc
 
+%rpmattr %_rpmlibdir/posttrans-filetriggers
+
 %rpmattr %_rpmlibdir/functions
 %rpmattr %_rpmlibdir/find-package
 %rpmdatattr %_rpmlibdir/.provides.sh
diff --git a/scripts/Makefile.am b/scripts/Makefile.am
index 6d5a5c1..b9900ba 100644
--- a/scripts/Makefile.am
+++ b/scripts/Makefile.am
@@ -3,6 +3,7 @@
 AUTOMAKE_OPTIONS = 1.4 foreign
 
 EXTRA_DIST = \
+	posttrans-filetriggers \
 	functions find-package .provides.sh \
 	find-scriptlet-requires \
 	brp-adjust_libraries brp-alt brp-bytecompile_python \
@@ -32,6 +33,7 @@ all:
 configdir = ${prefix}/lib/rpm
 config_DATA = .provides.sh 0common-files.req.list
 config_SCRIPTS = \
+	posttrans-filetriggers \
 	functions find-package \
 	find-scriptlet-requires \
 	brp-adjust_libraries brp-alt brp-bytecompile_python \
diff --git a/scripts/posttrans-filetriggers.in b/scripts/posttrans-filetriggers.in
new file mode 100755
index 0000000..1f80c51
--- /dev/null
+++ b/scripts/posttrans-filetriggers.in
@@ -0,0 +1,32 @@
+#!/bin/sh -efu
+#
+# File triggers are run at the end of successful transaction.
+#
+# Copyright (C) 2008  Alexey Tourbin <at@altlinux.org>
+#
+# Vaguely based on filetriggers.patch from Mandriva Linux.
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2 of the License, or
+# (at your option) any later version.
+
+filelist=$1
+shift
+
+RC=0
+
+if [ -s "$filelist" ]; then
+	LC_ALL=C sort -u -o "$filelist" "$filelist"
+	set +f
+	for filetrigger in @RPMCONFIGDIR@/*.filetrigger; do
+		[ -x "$filetrigger" ] || continue
+		"$filetrigger" <"$filelist" ||
+		{
+			echo >&2 "$filetrigger failed"
+			RC=1
+		}
+	done
+fi
+
+exit $RC

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

Re: [devel] posttrans filetriggers [2]

[Igor Vlasenko]

On Mon, Sep 08, 2008 at 01:51:06PM +0400, Alexey Tourbin wrote:
> Юрий Седунов просил меня реализовать posttrans filetriggers,
> чтобы решить проблему c gtk icon cache в branch-4.1 (для предостящего
> релиза дистрибутива).

Great news!
Осталось теперь просить майнтайнеров 
 desktop-file-utils (update-desktop-database)
 menu (update-menus) 
 xinitrc (update_wms)
оформить соответствующие filetriggers.

-- 

Dr. Igor Vlasenko
--------------------
Topology Department
Institute of Math
Kiev, Ukraine

Re: [devel] libgtk+2

[Dmitry V. Levin]

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

On Mon, Sep 08, 2008 at 01:51:06PM +0400, Alexey Tourbin wrote:
> Юрий Седунов просил меня реализовать posttrans filetriggers,
> чтобы решить проблему c gtk icon cache в branch-4.1 (для предостящего
> релиза дистрибутива).
> 
> Проблема это такая: библиотека libgtk+2 может использовать кеш
> иконок /usr/share/icons/hicolor/icon-theme.cache, чтобы ускорить
> загрузку иконок.  По умолчанию этот кеш отсутствует; но если он создан,
> то libgtk+2 не находит иконки, отсутствующие в кеше (но существующие в
> файловой системе).

Такое поведение libgtk+2 считаю глубоко порочным.  Представьте себе, что
ld-linux.so при наличии файла /etc/ld.so.cache будет игнорировать те
библиотеки в %_lib и %_libdir, которых в /etc/ld.so.cache нет.

Лучше исправить libgtk+2, чем городить объезды вокруг.


-- 
ldv

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

Re: [devel] libgtk+2

[Alexey Rusakov]

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

В Пнд, 08/09/2008 в 17:49 +0400, Dmitry V. Levin пишет:
> On Mon, Sep 08, 2008 at 01:51:06PM +0400, Alexey Tourbin wrote:
> > Юрий Седунов просил меня реализовать posttrans filetriggers,
> > чтобы решить проблему c gtk icon cache в branch-4.1 (для предостящего
> > релиза дистрибутива).
> > 
> > Проблема это такая: библиотека libgtk+2 может использовать кеш
> > иконок /usr/share/icons/hicolor/icon-theme.cache, чтобы ускорить
> > загрузку иконок.  По умолчанию этот кеш отсутствует; но если он создан,
> > то libgtk+2 не находит иконки, отсутствующие в кеше (но существующие в
> > файловой системе).
> 
> Такое поведение libgtk+2 считаю глубоко порочным.  Представьте себе, что
> ld-linux.so при наличии файла /etc/ld.so.cache будет игнорировать те
> библиотеки в %_lib и %_libdir, которых в /etc/ld.so.cache нет.
> 
> Лучше исправить libgtk+2, чем городить объезды вокруг.
Исправить, конечно, можно, но эффективности работы это не поспособствует
всё равно. Кэш иконок использовать крайне желательно, имхо.

-- 
  Alexey "Ktirf" Rusakov
  GNOME Project
  ALT Linux Team

[-- Attachment #2: Эта часть сообщения подписана цифровой подписью --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] libgtk+2

[Yuri N. Sedunov]

В Пнд, 08/09/2008 в 17:49 +0400, Dmitry V. Levin пишет:
> On Mon, Sep 08, 2008 at 01:51:06PM +0400, Alexey Tourbin wrote:
> > Юрий Седунов просил меня реализовать posttrans filetriggers,
> > чтобы решить проблему c gtk icon cache в branch-4.1 (для предостящего
> > релиза дистрибутива).
> > 
> > Проблема это такая: библиотека libgtk+2 может использовать кеш
> > иконок /usr/share/icons/hicolor/icon-theme.cache, чтобы ускорить
> > загрузку иконок.  По умолчанию этот кеш отсутствует; но если он создан,
> > то libgtk+2 не находит иконки, отсутствующие в кеше (но существующие в
> > файловой системе).
> 
> Такое поведение libgtk+2 считаю глубоко порочным.  Представьте себе, что
> ld-linux.so при наличии файла /etc/ld.so.cache будет игнорировать те
> библиотеки в %_lib и %_libdir, которых в /etc/ld.so.cache нет.
> 
> Лучше исправить libgtk+2, чем городить объезды вокруг.

Нет, -- механизм работает и отказываться от него не надо.

"GTK+ can use the cache files created by gtk-update-icon-cache to avoid
a lot of system call and disk seek overhead when the application starts.
Since the format of the cache files allows them to be mmap()ed shared
between multiple applications, the overall memory consumption is reduced
as well."

Re: [devel] libgtk+2

[Dmitry V. Levin]

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

On Mon, Sep 08, 2008 at 06:18:03PM +0400, Yuri N. Sedunov wrote:
> В Пнд, 08/09/2008 в 17:49 +0400, Dmitry V. Levin пишет:
> > On Mon, Sep 08, 2008 at 01:51:06PM +0400, Alexey Tourbin wrote:
> > > Юрий Седунов просил меня реализовать posttrans filetriggers,
> > > чтобы решить проблему c gtk icon cache в branch-4.1 (для предостящего
> > > релиза дистрибутива).
> > > 
> > > Проблема это такая: библиотека libgtk+2 может использовать кеш
> > > иконок /usr/share/icons/hicolor/icon-theme.cache, чтобы ускорить
> > > загрузку иконок.  По умолчанию этот кеш отсутствует; но если он создан,
> > > то libgtk+2 не находит иконки, отсутствующие в кеше (но существующие в
> > > файловой системе).
> > 
> > Такое поведение libgtk+2 считаю глубоко порочным.  Представьте себе, что
> > ld-linux.so при наличии файла /etc/ld.so.cache будет игнорировать те
> > библиотеки в %_lib и %_libdir, которых в /etc/ld.so.cache нет.
> > 
> > Лучше исправить libgtk+2, чем городить объезды вокруг.
> 
> Нет, -- механизм работает и отказываться от него не надо.

Механизм работает, но при этом содержит серьёзный архитектурный изъян,
из-за которого возникают проблемы.

> "GTK+ can use the cache files created by gtk-update-icon-cache to avoid
> a lot of system call and disk seek overhead when the application starts.
> Since the format of the cache files allows them to be mmap()ed shared
> between multiple applications, the overall memory consumption is reduced
> as well."

Из утверждения о том, что cache ускоряет работу, не следует, что cache
априори содержит более достоверную информацию, чем файлы, из которых он
построен.  Всякий cache нужно правильно invalidate'ить.


-- 
ldv

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

Re: [devel] libgtk+2

[Yuri N. Sedunov]

В Пнд, 08/09/2008 в 18:23 +0400, Dmitry V. Levin пишет:
> On Mon, Sep 08, 2008 at 06:18:03PM +0400, Yuri N. Sedunov wrote:
> > В Пнд, 08/09/2008 в 17:49 +0400, Dmitry V. Levin пишет:
> > > On Mon, Sep 08, 2008 at 01:51:06PM +0400, Alexey Tourbin wrote:
> > > > Юрий Седунов просил меня реализовать posttrans filetriggers,
> > > > чтобы решить проблему c gtk icon cache в branch-4.1 (для предостящего
> > > > релиза дистрибутива).
> > > > 
> > > > Проблема это такая: библиотека libgtk+2 может использовать кеш
> > > > иконок /usr/share/icons/hicolor/icon-theme.cache, чтобы ускорить
> > > > загрузку иконок.  По умолчанию этот кеш отсутствует; но если он создан,
> > > > то libgtk+2 не находит иконки, отсутствующие в кеше (но существующие в
> > > > файловой системе).
> > > 
> > > Такое поведение libgtk+2 считаю глубоко порочным.  Представьте себе, что
> > > ld-linux.so при наличии файла /etc/ld.so.cache будет игнорировать те
> > > библиотеки в %_lib и %_libdir, которых в /etc/ld.so.cache нет.
> > > 
> > > Лучше исправить libgtk+2, чем городить объезды вокруг.
> > 
> > Нет, -- механизм работает и отказываться от него не надо.
> 
> Механизм работает, но при этом содержит серьёзный архитектурный изъян,
> из-за которого возникают проблемы.

Проблемы возникают, если иконок нет в caсhe. Если gtk будет искать
отсутствующие в caсhe, получаются те же "a lot of system call and disk
seek overhead". Мне представляется поведение gtk логичным. 

> 
> > "GTK+ can use the cache files created by gtk-update-icon-cache to avoid
> > a lot of system call and disk seek overhead when the application starts.
> > Since the format of the cache files allows them to be mmap()ed shared
> > between multiple applications, the overall memory consumption is reduced
> > as well."
> 
> Из утверждения о том, что cache ускоряет работу, не следует, что cache
> априори содержит более достоверную информацию, чем файлы, из которых он
> построен.  Всякий cache нужно правильно invalidate'ить.

Как нужно правильно
invalidate'ить /usr/share/icons/hicolor/icon-theme.cache?

Re: [devel] libgtk+2

[Dmitry V. Levin]

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

On Mon, Sep 08, 2008 at 06:42:10PM +0400, Yuri N. Sedunov wrote:
> В Пнд, 08/09/2008 в 18:23 +0400, Dmitry V. Levin пишет:
> > On Mon, Sep 08, 2008 at 06:18:03PM +0400, Yuri N. Sedunov wrote:
> > > В Пнд, 08/09/2008 в 17:49 +0400, Dmitry V. Levin пишет:
> > > > On Mon, Sep 08, 2008 at 01:51:06PM +0400, Alexey Tourbin wrote:
> > > > > Юрий Седунов просил меня реализовать posttrans filetriggers,
> > > > > чтобы решить проблему c gtk icon cache в branch-4.1 (для предостящего
> > > > > релиза дистрибутива).
> > > > > 
> > > > > Проблема это такая: библиотека libgtk+2 может использовать кеш
> > > > > иконок /usr/share/icons/hicolor/icon-theme.cache, чтобы ускорить
> > > > > загрузку иконок.  По умолчанию этот кеш отсутствует; но если он создан,
> > > > > то libgtk+2 не находит иконки, отсутствующие в кеше (но существующие в
> > > > > файловой системе).
> > > > 
> > > > Такое поведение libgtk+2 считаю глубоко порочным.  Представьте себе, что
> > > > ld-linux.so при наличии файла /etc/ld.so.cache будет игнорировать те
> > > > библиотеки в %_lib и %_libdir, которых в /etc/ld.so.cache нет.
> > > > 
> > > > Лучше исправить libgtk+2, чем городить объезды вокруг.
> > > 
> > > Нет, -- механизм работает и отказываться от него не надо.
> > 
> > Механизм работает, но при этом содержит серьёзный архитектурный изъян,
> > из-за которого возникают проблемы.
> 
> Проблемы возникают, если иконок нет в caсhe. Если gtk будет искать
> отсутствующие в caсhe, получаются те же "a lot of system call and disk
> seek overhead". Мне представляется поведение gtk логичным. 

А если ld-linux.so не будет запускать ELF'ы после смены soname до запуска
ldconfig'а, разве это тоже будет логично?

> > > "GTK+ can use the cache files created by gtk-update-icon-cache to avoid
> > > a lot of system call and disk seek overhead when the application starts.
> > > Since the format of the cache files allows them to be mmap()ed shared
> > > between multiple applications, the overall memory consumption is reduced
> > > as well."
> > 
> > Из утверждения о том, что cache ускоряет работу, не следует, что cache
> > априори содержит более достоверную информацию, чем файлы, из которых он
> > построен.  Всякий cache нужно правильно invalidate'ить.
> 
> Как нужно правильно
> invalidate'ить /usr/share/icons/hicolor/icon-theme.cache?

Полагаю, надо искать файл по файловой системе, ЕСЛИ его не нашлось
в icon-theme.cache


-- 
ldv

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

Re: [devel] libgtk+2

[Yuri N. Sedunov]

В Пнд, 08/09/2008 в 18:46 +0400, Dmitry V. Levin пишет:
> On Mon, Sep 08, 2008 at 06:42:10PM +0400, Yuri N. Sedunov wrote:
> > В Пнд, 08/09/2008 в 18:23 +0400, Dmitry V. Levin пишет:
> > > On Mon, Sep 08, 2008 at 06:18:03PM +0400, Yuri N. Sedunov wrote:
> > > > В Пнд, 08/09/2008 в 17:49 +0400, Dmitry V. Levin пишет:
> > > > > On Mon, Sep 08, 2008 at 01:51:06PM +0400, Alexey Tourbin wrote:
> > > > > > Юрий Седунов просил меня реализовать posttrans filetriggers,
> > > > > > чтобы решить проблему c gtk icon cache в branch-4.1 (для предостящего
> > > > > > релиза дистрибутива).
> > > > > > 
> > > > > > Проблема это такая: библиотека libgtk+2 может использовать кеш
> > > > > > иконок /usr/share/icons/hicolor/icon-theme.cache, чтобы ускорить
> > > > > > загрузку иконок.  По умолчанию этот кеш отсутствует; но если он создан,
> > > > > > то libgtk+2 не находит иконки, отсутствующие в кеше (но существующие в
> > > > > > файловой системе).
> > > > > 
> > > > > Такое поведение libgtk+2 считаю глубоко порочным.  Представьте себе, что
> > > > > ld-linux.so при наличии файла /etc/ld.so.cache будет игнорировать те
> > > > > библиотеки в %_lib и %_libdir, которых в /etc/ld.so.cache нет.
> > > > > 
> > > > > Лучше исправить libgtk+2, чем городить объезды вокруг.
> > > > 
> > > > Нет, -- механизм работает и отказываться от него не надо.
> > > 
> > > Механизм работает, но при этом содержит серьёзный архитектурный изъян,
> > > из-за которого возникают проблемы.
> > 
> > Проблемы возникают, если иконок нет в caсhe. Если gtk будет искать
> > отсутствующие в caсhe, получаются те же "a lot of system call and disk
> > seek overhead". Мне представляется поведение gtk логичным. 
> 
> А если ld-linux.so не будет запускать ELF'ы после смены soname до запуска
> ldconfig'а, разве это тоже будет логично?

Давай не все в одну кучу сваливать,  А то договоримся, что,
например, .schemas не надо устанавливать, а надо GConf научить
шерстить  /etc/gconf/schemas/ в поисках нужного ключа и самому обновлять
свою базу.

> > > > "GTK+ can use the cache files created by gtk-update-icon-cache to avoid
> > > > a lot of system call and disk seek overhead when the application starts.
> > > > Since the format of the cache files allows them to be mmap()ed shared
> > > > between multiple applications, the overall memory consumption is reduced
> > > > as well."
> > > 
> > > Из утверждения о том, что cache ускоряет работу, не следует, что cache
> > > априори содержит более достоверную информацию, чем файлы, из которых он
> > > построен.  Всякий cache нужно правильно invalidate'ить.
> > 
> > Как нужно правильно
> > invalidate'ить /usr/share/icons/hicolor/icon-theme.cache?
> 
> Полагаю, надо искать файл по файловой системе, ЕСЛИ его не нашлось
> в icon-theme.cache

Это предложение равносильно тому, чтобы не использовать icon-theme.cache
совсем.  

Re: [devel] libgtk+2

[Mikhail Gusarov]

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

Twas brillig at 19:15:18 08.09.2008 UTC+04 when aris@altlinux.org did gyre and gimble:

 >> Полагаю, надо искать файл по файловой системе, ЕСЛИ его не нашлось
 >> в icon-theme.cache

 YNS> Это предложение равносильно тому, чтобы не использовать
 YNS> icon-theme.cache совсем.

Это предложение делает icon-theme.cache КЭШЕМ, как на нём и
написано. Кэш обязан никак не влиять на семантику, а только на
производительность, о чём детки из GNOME, видать, забыли.

-- 

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

Re: [devel] libgtk+2

[Andrey Rahmatullin]

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

On Mon, Sep 08, 2008 at 07:15:18PM +0400, Yuri N. Sedunov wrote:
> > Полагаю, надо искать файл по файловой системе, ЕСЛИ его не нашлось
> > в icon-theme.cache
> Это предложение равносильно тому, чтобы не использовать icon-theme.cache
> совсем.  
Такишо, даже если файл есть в кэше??

-- 
WBR, wRAR (ALT Linux Team)
Powered by the ALT Linux fortune(8):

Пока что я предлагаю сделать синий синим, ибо иначе мы реально не успеем все
перелопатить к master'у.
		-- rider in #4538

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

Re: [devel] libgtk+2

[Alexey Rusakov]

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

В Пнд, 08/09/2008 в 19:15 +0400, Yuri N. Sedunov пишет:
> В Пнд, 08/09/2008 в 18:46 +0400, Dmitry V. Levin пишет:
> > On Mon, Sep 08, 2008 at 06:42:10PM +0400, Yuri N. Sedunov wrote:
> > > В Пнд, 08/09/2008 в 18:23 +0400, Dmitry V. Levin пишет:
> > > > On Mon, Sep 08, 2008 at 06:18:03PM +0400, Yuri N. Sedunov wrote:
> > > > > В Пнд, 08/09/2008 в 17:49 +0400, Dmitry V. Levin пишет:
> > > > > > On Mon, Sep 08, 2008 at 01:51:06PM +0400, Alexey Tourbin wrote:
> > > > > > > Юрий Седунов просил меня реализовать posttrans filetriggers,
> > > > > > > чтобы решить проблему c gtk icon cache в branch-4.1 (для предостящего
> > > > > > > релиза дистрибутива).
> > > > > > > 
> > > > > > > Проблема это такая: библиотека libgtk+2 может использовать кеш
> > > > > > > иконок /usr/share/icons/hicolor/icon-theme.cache, чтобы ускорить
> > > > > > > загрузку иконок.  По умолчанию этот кеш отсутствует; но если он создан,
> > > > > > > то libgtk+2 не находит иконки, отсутствующие в кеше (но существующие в
> > > > > > > файловой системе).
> > > > > > 
> > > > > > Такое поведение libgtk+2 считаю глубоко порочным.  Представьте себе, что
> > > > > > ld-linux.so при наличии файла /etc/ld.so.cache будет игнорировать те
> > > > > > библиотеки в %_lib и %_libdir, которых в /etc/ld.so.cache нет.
> > > > > > 
> > > > > > Лучше исправить libgtk+2, чем городить объезды вокруг.
> > > > > 
> > > > > Нет, -- механизм работает и отказываться от него не надо.
> > > > 
> > > > Механизм работает, но при этом содержит серьёзный архитектурный изъян,
> > > > из-за которого возникают проблемы.
> > > 
> > > Проблемы возникают, если иконок нет в caсhe. Если gtk будет искать
> > > отсутствующие в caсhe, получаются те же "a lot of system call and disk
> > > seek overhead". Мне представляется поведение gtk логичным. 
> > 
> > А если ld-linux.so не будет запускать ELF'ы после смены soname до запуска
> > ldconfig'а, разве это тоже будет логично?
> 
> Давай не все в одну кучу сваливать,  А то договоримся, что,
> например, .schemas не надо устанавливать, а надо GConf научить
> шерстить  /etc/gconf/schemas/ в поисках нужного ключа и самому обновлять
> свою базу.
> 
> > > > > "GTK+ can use the cache files created by gtk-update-icon-cache to avoid
> > > > > a lot of system call and disk seek overhead when the application starts.
> > > > > Since the format of the cache files allows them to be mmap()ed shared
> > > > > between multiple applications, the overall memory consumption is reduced
> > > > > as well."
> > > > 
> > > > Из утверждения о том, что cache ускоряет работу, не следует, что cache
> > > > априори содержит более достоверную информацию, чем файлы, из которых он
> > > > построен.  Всякий cache нужно правильно invalidate'ить.
> > > 
> > > Как нужно правильно
> > > invalidate'ить /usr/share/icons/hicolor/icon-theme.cache?
> > 
> > Полагаю, надо искать файл по файловой системе, ЕСЛИ его не нашлось
> > в icon-theme.cache
> 
> Это предложение равносильно тому, чтобы не использовать icon-theme.cache
> совсем.  
Не равносильно. Если иконка существует в кэше, она оттуда будет (быстро)
взята. А вот если её нет... 
В принципе, если воспринимать icon-theme.cache не как кэш, а poor-man's
прокси-сервер, поставляющий иконки, то его действительно нужно обновлять
при каждой установке иконок и брать иконки только оттуда. Либо патчить
Gtk+ на предмет того, чтобы она обращалась с ним действительно как с
кэшом. Но тогда, извините, нужно ещё, чтобы Gtk+ кэшировала найденные
иконки. А то иначе какой-то однобокий кэш получается.

-- 
  Alexey "Ktirf" Rusakov
  GNOME Project
  ALT Linux Team

[-- Attachment #2: Эта часть сообщения подписана цифровой подписью --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [devel] libgtk+2

[Dmitry V. Levin]

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

On Mon, Sep 08, 2008 at 07:15:18PM +0400, Yuri N. Sedunov wrote:
> В Пнд, 08/09/2008 в 18:46 +0400, Dmitry V. Levin пишет:
> > On Mon, Sep 08, 2008 at 06:42:10PM +0400, Yuri N. Sedunov wrote:
> > > В Пнд, 08/09/2008 в 18:23 +0400, Dmitry V. Levin пишет:
> > > > On Mon, Sep 08, 2008 at 06:18:03PM +0400, Yuri N. Sedunov wrote:
> > > > > В Пнд, 08/09/2008 в 17:49 +0400, Dmitry V. Levin пишет:
> > > > > > On Mon, Sep 08, 2008 at 01:51:06PM +0400, Alexey Tourbin wrote:
> > > > > > > Юрий Седунов просил меня реализовать posttrans filetriggers,
> > > > > > > чтобы решить проблему c gtk icon cache в branch-4.1 (для предостящего
> > > > > > > релиза дистрибутива).
> > > > > > > 
> > > > > > > Проблема это такая: библиотека libgtk+2 может использовать кеш
> > > > > > > иконок /usr/share/icons/hicolor/icon-theme.cache, чтобы ускорить
> > > > > > > загрузку иконок.  По умолчанию этот кеш отсутствует; но если он создан,
> > > > > > > то libgtk+2 не находит иконки, отсутствующие в кеше (но существующие в
> > > > > > > файловой системе).
> > > > > > 
> > > > > > Такое поведение libgtk+2 считаю глубоко порочным.  Представьте себе, что
> > > > > > ld-linux.so при наличии файла /etc/ld.so.cache будет игнорировать те
> > > > > > библиотеки в %_lib и %_libdir, которых в /etc/ld.so.cache нет.
> > > > > > 
> > > > > > Лучше исправить libgtk+2, чем городить объезды вокруг.
> > > > > 
> > > > > Нет, -- механизм работает и отказываться от него не надо.
> > > > 
> > > > Механизм работает, но при этом содержит серьёзный архитектурный изъян,
> > > > из-за которого возникают проблемы.
> > > 
> > > Проблемы возникают, если иконок нет в caсhe. Если gtk будет искать
> > > отсутствующие в caсhe, получаются те же "a lot of system call and disk
> > > seek overhead". Мне представляется поведение gtk логичным. 
> > 
> > А если ld-linux.so не будет запускать ELF'ы после смены soname до запуска
> > ldconfig'а, разве это тоже будет логично?
> 
> Давай не все в одну кучу сваливать,

Я привёл эту аналогию потому, что она мне показалась совершенно
естественной.  Не вижу принципиальной разницы между этими кэшами.

> > > Как нужно правильно
> > > invalidate'ить /usr/share/icons/hicolor/icon-theme.cache?
> > 
> > Полагаю, надо искать файл по файловой системе, ЕСЛИ его не нашлось
> > в icon-theme.cache
> 
> Это предложение равносильно тому, чтобы не использовать icon-theme.cache
> совсем.  

Отнюдь.  Это естественный порядок вещей для пользовательского кэша части
файловой системы.


-- 
ldv

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

Re: [devel] libgtk+2

[Yuri N. Sedunov]

В Пнд, 08/09/2008 в 19:26 +0400, Alexey Rusakov пишет:
<skip>
> > Это предложение равносильно тому, чтобы не использовать icon-theme.cache
> > совсем.  
> Не равносильно. Если иконка существует в кэше, она оттуда будет (быстро)
> взята. А вот если её нет... 

Именно потому и равносильно, что вероятность оказаться в кеше в нашей
системе у конкретной иконки невелика.

> В принципе, если воспринимать icon-theme.cache не как кэш, а poor-man's
> прокси-сервер, поставляющий иконки, то его действительно нужно обновлять
> при каждой установке иконок и брать иконки только оттуда. 

Именно, надо обновлять icon-theme.cache. Вопрос лишь в средствах.  

> Либо патчить
> Gtk+ на предмет того, чтобы она обращалась с ним действительно как с
> кэшом. Но тогда, извините, нужно ещё, чтобы Gtk+ кэшировала найденные
> иконки. А то иначе какой-то однобокий кэш получается.

Re: [devel] libgtk+2

[Dmitry V. Levin]

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

On Mon, Sep 08, 2008 at 07:41:52PM +0400, Yuri N. Sedunov wrote:
> В Пнд, 08/09/2008 в 19:26 +0400, Alexey Rusakov пишет:
> <skip>
> > > Это предложение равносильно тому, чтобы не использовать icon-theme.cache
> > > совсем.  
> > Не равносильно. Если иконка существует в кэше, она оттуда будет (быстро)
> > взята. А вот если её нет... 
> 
> Именно потому и равносильно, что вероятность оказаться в кеше в нашей
> системе у конкретной иконки невелика.

Это может измениться со временем.

> > В принципе, если воспринимать icon-theme.cache не как кэш, а poor-man's
> > прокси-сервер, поставляющий иконки, то его действительно нужно обновлять
> > при каждой установке иконок и брать иконки только оттуда. 
> 
> Именно, надо обновлять icon-theme.cache. Вопрос лишь в средствах.  

Надо не только поддерживать icon-theme.cache в актуальном состоянии, но и
корректно обрабатывать неактуальный icon-theme.cache, который сейчас очень
легко получить.


-- 
ldv

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

Re: [devel] libgtk+2

[Yuri N. Sedunov]

В Пнд, 08/09/2008 в 19:46 +0400, Dmitry V. Levin пишет:
> On Mon, Sep 08, 2008 at 07:41:52PM +0400, Yuri N. Sedunov wrote:
> > В Пнд, 08/09/2008 в 19:26 +0400, Alexey Rusakov пишет:
> > <skip>
> > > > Это предложение равносильно тому, чтобы не использовать icon-theme.cache
> > > > совсем.  
> > > Не равносильно. Если иконка существует в кэше, она оттуда будет (быстро)
> > > взята. А вот если её нет... 
> > 
> > Именно потому и равносильно, что вероятность оказаться в кеше в нашей
> > системе у конкретной иконки невелика.
> 
> Это может измениться со временем.
> 
> > > В принципе, если воспринимать icon-theme.cache не как кэш, а poor-man's
> > > прокси-сервер, поставляющий иконки, то его действительно нужно обновлять
> > > при каждой установке иконок и брать иконки только оттуда. 
> > 
> > Именно, надо обновлять icon-theme.cache. Вопрос лишь в средствах.  
> 
> Надо не только поддерживать icon-theme.cache в актуальном состоянии, но и
> корректно обрабатывать неактуальный icon-theme.cache, который сейчас очень
> легко получить.

Актуальный icon-theme.cache есть только на livecd и его актуальность
обеспечена системными средствами. Предлагается и на неживых системах
решить вопрос системно без потери производительности.

Re: [devel] libgtk+2

[Sergey V Turchin]

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

On Monday 08 September 2008, Yuri N. Sedunov wrote:

[...]
> Актуальный icon-theme.cache есть только на livecd и его
> актуальность обеспечена системными средствами.
Т.е. иконки ~/ идут лесом?
Почему бы не делать кэш системных+домашних иконок в ~/.icons/theme/ 
?

-- 
Regards, Sergey, ALT Linux Team, http://www.altlinux.ru
http://stinkfoot.org:11371/pks/lookup?op=get&search=0x1C2A3F08

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

[devel] /etc/ld.so.cache

[Alexey Tourbin]

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

On Mon, Sep 08, 2008 at 05:49:58PM +0400, Dmitry V. Levin wrote:
> On Mon, Sep 08, 2008 at 01:51:06PM +0400, Alexey Tourbin wrote:
> > Юрий Седунов просил меня реализовать posttrans filetriggers,
> > чтобы решить проблему c gtk icon cache в branch-4.1 (для предостящего
> > релиза дистрибутива).
> > 
> > Проблема это такая: библиотека libgtk+2 может использовать кеш
> > иконок /usr/share/icons/hicolor/icon-theme.cache, чтобы ускорить
> > загрузку иконок.  По умолчанию этот кеш отсутствует; но если он создан,
> > то libgtk+2 не находит иконки, отсутствующие в кеше (но существующие в
> > файловой системе).
> 
> Такое поведение libgtk+2 считаю глубоко порочным.  Представьте себе, что
> ld-linux.so при наличии файла /etc/ld.so.cache будет игнорировать те
> библиотеки в %_lib и %_libdir, которых в /etc/ld.so.cache нет.

А как ведёт себя ld-linux.so, если путь из кеша даёт ENOENT?
Такая ситуация может возникнуть при перекладывании библиотек между
/%_lib и %_libdir.  Если бы ENOENT считался как отсутствие в кеше,
при котором запускается обычный поиск в каталогах, тогда можно было
бы откладывать вызов ldconfig до окончания транзакции.

Кстати, возможно, имеет ли смысл использовать 'ldconfig -X'.
Перестановка симлинков (по отношению к rpm пакетам) -- очень
сомнительная фича (и она даёт проблему в %post_ldconfig при
даунгрейде библиотек).

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

Re: [devel] /etc/ld.so.cache

[Dmitry V. Levin]

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

On Thu, Sep 11, 2008 at 11:25:42PM +0400, Alexey Tourbin wrote:
> On Mon, Sep 08, 2008 at 05:49:58PM +0400, Dmitry V. Levin wrote:
> > On Mon, Sep 08, 2008 at 01:51:06PM +0400, Alexey Tourbin wrote:
> > > Юрий Седунов просил меня реализовать posttrans filetriggers,
> > > чтобы решить проблему c gtk icon cache в branch-4.1 (для предостящего
> > > релиза дистрибутива).
> > > 
> > > Проблема это такая: библиотека libgtk+2 может использовать кеш
> > > иконок /usr/share/icons/hicolor/icon-theme.cache, чтобы ускорить
> > > загрузку иконок.  По умолчанию этот кеш отсутствует; но если он создан,
> > > то libgtk+2 не находит иконки, отсутствующие в кеше (но существующие в
> > > файловой системе).
> > 
> > Такое поведение libgtk+2 считаю глубоко порочным.  Представьте себе, что
> > ld-linux.so при наличии файла /etc/ld.so.cache будет игнорировать те
> > библиотеки в %_lib и %_libdir, которых в /etc/ld.so.cache нет.
> 
> А как ведёт себя ld-linux.so, если путь из кеша даёт ENOENT?

Будет искать по файловой системе согласно /etc/ld.so.conf

> Такая ситуация может возникнуть при перекладывании библиотек между
> /%_lib и %_libdir.  Если бы ENOENT считался как отсутствие в кеше,

Именно так.

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

Да, вызов ldconfig можно откладывать до окончания транзакции, если
пренебречь одним обстоятельством, о котором идёт речь ниже.

> Кстати, возможно, имеет ли смысл использовать 'ldconfig -X'.
> Перестановка симлинков (по отношению к rpm пакетам) -- очень
> сомнительная фича (и она даёт проблему в %post_ldconfig при
> даунгрейде библиотек).

Это объезд для пакетов, в которых забыли упаковать эти ссылки.


-- 
ldv

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

Re: [devel] /etc/ld.so.cache

[Alexey Tourbin]

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

On Thu, Sep 11, 2008 at 11:58:00PM +0400, Dmitry V. Levin wrote:
> > А как ведёт себя ld-linux.so, если путь из кеша даёт ENOENT?
> 
> Будет искать по файловой системе согласно /etc/ld.so.conf
> 
> > Такая ситуация может возникнуть при перекладывании библиотек между
> > /%_lib и %_libdir.  Если бы ENOENT считался как отсутствие в кеше,
> 
> Именно так.
> 
> > при котором запускается обычный поиск в каталогах, тогда можно было
> > бы откладывать вызов ldconfig до окончания транзакции.
> 
> Да, вызов ldconfig можно откладывать до окончания транзакции, если
> пренебречь одним обстоятельством, о котором идёт речь ниже.
> 
> > Кстати, возможно, имеет ли смысл использовать 'ldconfig -X'.
> > Перестановка симлинков (по отношению к rpm пакетам) -- очень
> > сомнительная фича (и она даёт проблему в %post_ldconfig при
> > даунгрейде библиотек).
> 
> Это объезд для пакетов, в которых забыли упаковать эти ссылки.

А есть ли такие пакеты?  Ведь lib.prov выставляет provides на soname
только в том случае, если имя файла/симлинка совпадает с названием
сонейма.

$ /usr/lib/rpm/lib.prov -vv /lib64/libglib-2.0.so.0*
lib.prov: processing /lib64/libglib-2.0.so.0
libglib-2.0.so.0()(64bit)
libglib-2.0.so.0(GLIB_2.8)(64bit)
libglib-2.0.so.0(GLIB_2.10)(64bit)
libglib-2.0.so.0(GLIB_2.12)(64bit)
libglib-2.0.so.0(GLIB_2.14)(64bit)
libglib-2.0.so.0(GLIB_2.15.6)(64bit)
lib.prov: processing /lib64/libglib-2.0.so.0.1600.5
$ 

Если бы мы забыли запаковать симлинк /lib64/libglib-2.0.so.0,
то бинарик /lib64/libglib-2.0.so.0.1600.5 не дал бы provides;
пакет, в котором забыли запаковать "значащий" симлинк, либо даст
анметы, либо просто этот сонейм никому не нужен (так что симлинк
можно и не делать).

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

Re: [devel] /etc/ld.so.cache

[Dmitry V. Levin]

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

On Fri, Sep 12, 2008 at 12:16:43AM +0400, Alexey Tourbin wrote:
> On Thu, Sep 11, 2008 at 11:58:00PM +0400, Dmitry V. Levin wrote:
> > > А как ведёт себя ld-linux.so, если путь из кеша даёт ENOENT?
> > 
> > Будет искать по файловой системе согласно /etc/ld.so.conf
> > 
> > > Такая ситуация может возникнуть при перекладывании библиотек между
> > > /%_lib и %_libdir.  Если бы ENOENT считался как отсутствие в кеше,
> > 
> > Именно так.
> > 
> > > при котором запускается обычный поиск в каталогах, тогда можно было
> > > бы откладывать вызов ldconfig до окончания транзакции.
> > 
> > Да, вызов ldconfig можно откладывать до окончания транзакции, если
> > пренебречь одним обстоятельством, о котором идёт речь ниже.
> > 
> > > Кстати, возможно, имеет ли смысл использовать 'ldconfig -X'.
> > > Перестановка симлинков (по отношению к rpm пакетам) -- очень
> > > сомнительная фича (и она даёт проблему в %post_ldconfig при
> > > даунгрейде библиотек).
> > 
> > Это объезд для пакетов, в которых забыли упаковать эти ссылки.
> 
> А есть ли такие пакеты?  Ведь lib.prov выставляет provides на soname
> только в том случае, если имя файла/симлинка совпадает с названием
> сонейма.

Этот объезд гораздо старше lib.prov

> $ /usr/lib/rpm/lib.prov -vv /lib64/libglib-2.0.so.0*
> lib.prov: processing /lib64/libglib-2.0.so.0
> libglib-2.0.so.0()(64bit)
> libglib-2.0.so.0(GLIB_2.8)(64bit)
> libglib-2.0.so.0(GLIB_2.10)(64bit)
> libglib-2.0.so.0(GLIB_2.12)(64bit)
> libglib-2.0.so.0(GLIB_2.14)(64bit)
> libglib-2.0.so.0(GLIB_2.15.6)(64bit)
> lib.prov: processing /lib64/libglib-2.0.so.0.1600.5
> $ 
> 
> Если бы мы забыли запаковать симлинк /lib64/libglib-2.0.so.0,
> то бинарик /lib64/libglib-2.0.so.0.1600.5 не дал бы provides;
> пакет, в котором забыли запаковать "значащий" симлинк, либо даст
> анметы, либо просто этот сонейм никому не нужен (так что симлинк
> можно и не делать).

OK, есть ещё какие-нибудь основания запускать ldconfig таким образом,
как это делается в пакетах сейчас?


-- 
ldv

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

Re: [devel] /etc/ld.so.cache

[Alexey Tourbin]

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

On Fri, Sep 12, 2008 at 12:20:12AM +0400, Dmitry V. Levin wrote:
> > > > Кстати, возможно, имеет ли смысл использовать 'ldconfig -X'.
> > > > Перестановка симлинков (по отношению к rpm пакетам) -- очень
> > > > сомнительная фича (и она даёт проблему в %post_ldconfig при
> > > > даунгрейде библиотек).
> > > 
> > > Это объезд для пакетов, в которых забыли упаковать эти ссылки.
> > 
> > А есть ли такие пакеты?  Ведь lib.prov выставляет provides на soname
> > только в том случае, если имя файла/симлинка совпадает с названием
> > сонейма.
> 
> Этот объезд гораздо старше lib.prov

Понятно.

> > $ /usr/lib/rpm/lib.prov -vv /lib64/libglib-2.0.so.0*
> > lib.prov: processing /lib64/libglib-2.0.so.0
> > libglib-2.0.so.0()(64bit)
> > libglib-2.0.so.0(GLIB_2.8)(64bit)
> > libglib-2.0.so.0(GLIB_2.10)(64bit)
> > libglib-2.0.so.0(GLIB_2.12)(64bit)
> > libglib-2.0.so.0(GLIB_2.14)(64bit)
> > libglib-2.0.so.0(GLIB_2.15.6)(64bit)
> > lib.prov: processing /lib64/libglib-2.0.so.0.1600.5
> > $ 
> > 
> > Если бы мы забыли запаковать симлинк /lib64/libglib-2.0.so.0,
> > то бинарик /lib64/libglib-2.0.so.0.1600.5 не дал бы provides;
> > пакет, в котором забыли запаковать "значащий" симлинк, либо даст
> > анметы, либо просто этот сонейм никому не нужен (так что симлинк
> > можно и не делать).
> 
> OK, есть ещё какие-нибудь основания запускать ldconfig таким образом,
> как это делается в пакетах сейчас?

В перспективе (но, наверное, не самой ближайшей) стоит отказаться
от вызова ldconfig в пакетах и сделать posttrans trigger.  Кстати,
там уже можно вызывать ldconfig и без опции -X, потому что при окончании
транзакции проблемы даунгрейда библиотек не существует (старые файлы
полностью удалены).  Так что даже можно обслужить и левые пакеты.

Кстати, вот как это сделано в Мандриве (glibc-2.8-1.20080520.5mnb2.src.rpm),
glibc.spec:
  1015  # automatic ldconfig cache update on rpm installs/removals
  1016  # (see http://wiki.mandriva.com/en/Rpm_filetriggers)
  1017  install -d %buildroot%{_var}/lib/rpm/filetriggers
  1018  cat > %buildroot%{_var}/lib/rpm/filetriggers/ldconfig.filter << EOF
  1019  ^.((/lib|/usr/lib)(64)?/[^/]*\.so\.|/etc/ld.so.conf.d/[^/]*\.conf)
  1020  EOF
  1021  cat > %buildroot%{_var}/lib/rpm/filetriggers/ldconfig.script << EOF
  1022  #!/bin/sh
  1023  ldconfig -X
  1024  EOF
  1025  chmod 755 %buildroot%{_var}/lib/rpm/filetriggers/ldconfig.script

Кривовато, конечно (как и многое в Мандриве), можно сделать чуть лучше.
В идеале, конечно, нужен триггер не по файлам, а по provides.

Кстати, вот чем мне не понравился именно такой подход к реализации.
С одной стороны, они вделывают regcomp() в librpm, по-видимому, чтобы
избежать лишних зависимостей на уровне exec (внутренний glob+grep сидит
в librpm).  C другой стороны, им не удаётся отказаться от /bin/sh даже
для ldconfig.

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

Re: [devel] /etc/ld.so.cache

[Alexey Tourbin]

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

On Fri, Sep 12, 2008 at 12:38:23AM +0400, Alexey Tourbin wrote:
> В перспективе (но, наверное, не самой ближайшей) стоит отказаться
> от вызова ldconfig в пакетах и сделать posttrans trigger.  Кстати,
> там уже можно вызывать ldconfig и без опции -X, потому что при окончании
> транзакции проблемы даунгрейда библиотек не существует (старые файлы
> полностью удалены).  Так что даже можно обслужить и левые пакеты.
> 
> Кстати, вот как это сделано в Мандриве (glibc-2.8-1.20080520.5mnb2.src.rpm),
> glibc.spec:
>   1015  # automatic ldconfig cache update on rpm installs/removals
>   1016  # (see http://wiki.mandriva.com/en/Rpm_filetriggers)
>   1017  install -d %buildroot%{_var}/lib/rpm/filetriggers
>   1018  cat > %buildroot%{_var}/lib/rpm/filetriggers/ldconfig.filter << EOF
>   1019  ^.((/lib|/usr/lib)(64)?/[^/]*\.so\.|/etc/ld.so.conf.d/[^/]*\.conf)
>   1020  EOF
>   1021  cat > %buildroot%{_var}/lib/rpm/filetriggers/ldconfig.script << EOF
>   1022  #!/bin/sh
>   1023  ldconfig -X
>   1024  EOF
>   1025  chmod 755 %buildroot%{_var}/lib/rpm/filetriggers/ldconfig.script

Кстати, при подобном раскладе (если содержать триггер в glibc-core),
у пакета glibc-core появится зависимость на sh (а у sh уже есть
зависимость на glibc-core).  Впрочем, триггер можно написать на Си...

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

Re: [devel] /etc/ld.so.cache

[Dmitry V. Levin]

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

On Fri, Sep 12, 2008 at 12:38:23AM +0400, Alexey Tourbin wrote:
[...]
> > OK, есть ещё какие-нибудь основания запускать ldconfig таким образом,
> > как это делается в пакетах сейчас?
> 
> В перспективе (но, наверное, не самой ближайшей) стоит отказаться
> от вызова ldconfig в пакетах и сделать posttrans trigger.

Почему не ближайшей?  Когда будет готов этот триггер, можно будет начинать
убирать ldconfig'и.

> Кстати,
> там уже можно вызывать ldconfig и без опции -X, потому что при окончании
> транзакции проблемы даунгрейда библиотек не существует (старые файлы
> полностью удалены).  Так что даже можно обслужить и левые пакеты.

Да, пожалуй.

> Кстати, вот как это сделано в Мандриве (glibc-2.8-1.20080520.5mnb2.src.rpm),
> glibc.spec:
>   1015  # automatic ldconfig cache update on rpm installs/removals
>   1016  # (see http://wiki.mandriva.com/en/Rpm_filetriggers)
>   1017  install -d %buildroot%{_var}/lib/rpm/filetriggers
>   1018  cat > %buildroot%{_var}/lib/rpm/filetriggers/ldconfig.filter << EOF
>   1019  ^.((/lib|/usr/lib)(64)?/[^/]*\.so\.|/etc/ld.so.conf.d/[^/]*\.conf)
>   1020  EOF
>   1021  cat > %buildroot%{_var}/lib/rpm/filetriggers/ldconfig.script << EOF
>   1022  #!/bin/sh
>   1023  ldconfig -X
>   1024  EOF
>   1025  chmod 755 %buildroot%{_var}/lib/rpm/filetriggers/ldconfig.script
> 
> Кривовато, конечно (как и многое в Мандриве), можно сделать чуть лучше.
> В идеале, конечно, нужен триггер не по файлам, а по provides.
> 
> Кстати, вот чем мне не понравился именно такой подход к реализации.
> С одной стороны, они вделывают regcomp() в librpm, по-видимому, чтобы
> избежать лишних зависимостей на уровне exec (внутренний glob+grep сидит
> в librpm).  C другой стороны, им не удаётся отказаться от /bin/sh даже
> для ldconfig.

Они даже exec не написали, так что я думаю, что их этот /bin/sh совершенно
не смущает.


-- 
ldv

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

Re: [devel] /etc/ld.so.cache

[Dmitry V. Levin]

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

On Fri, Sep 12, 2008 at 12:48:09AM +0400, Alexey Tourbin wrote:
> On Fri, Sep 12, 2008 at 12:38:23AM +0400, Alexey Tourbin wrote:
> > В перспективе (но, наверное, не самой ближайшей) стоит отказаться
> > от вызова ldconfig в пакетах и сделать posttrans trigger.  Кстати,
> > там уже можно вызывать ldconfig и без опции -X, потому что при окончании
> > транзакции проблемы даунгрейда библиотек не существует (старые файлы
> > полностью удалены).  Так что даже можно обслужить и левые пакеты.
> > 
> > Кстати, вот как это сделано в Мандриве (glibc-2.8-1.20080520.5mnb2.src.rpm),
> > glibc.spec:
> >   1015  # automatic ldconfig cache update on rpm installs/removals
> >   1016  # (see http://wiki.mandriva.com/en/Rpm_filetriggers)
> >   1017  install -d %buildroot%{_var}/lib/rpm/filetriggers
> >   1018  cat > %buildroot%{_var}/lib/rpm/filetriggers/ldconfig.filter << EOF
> >   1019  ^.((/lib|/usr/lib)(64)?/[^/]*\.so\.|/etc/ld.so.conf.d/[^/]*\.conf)
> >   1020  EOF
> >   1021  cat > %buildroot%{_var}/lib/rpm/filetriggers/ldconfig.script << EOF
> >   1022  #!/bin/sh
> >   1023  ldconfig -X
> >   1024  EOF
> >   1025  chmod 755 %buildroot%{_var}/lib/rpm/filetriggers/ldconfig.script
> 
> Кстати, при подобном раскладе (если содержать триггер в glibc-core),
> у пакета glibc-core появится зависимость на sh (а у sh уже есть
> зависимость на glibc-core).  Впрочем, триггер можно написать на Си...

В glibc-core уже есть несколько таких скриптов на C.
А вот если там появится зависимость на @RPMCONFIGDIR@, то будет не очень
здорово.


-- 
ldv

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

Re: [devel] /etc/ld.so.cache

[Alexey Tourbin]

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

On Fri, Sep 12, 2008 at 12:53:29AM +0400, Dmitry V. Levin wrote:
> > > Кстати, вот как это сделано в Мандриве (glibc-2.8-1.20080520.5mnb2.src.rpm),
> > > glibc.spec:
> > >   1015  # automatic ldconfig cache update on rpm installs/removals
> > >   1016  # (see http://wiki.mandriva.com/en/Rpm_filetriggers)
> > >   1017  install -d %buildroot%{_var}/lib/rpm/filetriggers
> > >   1018  cat > %buildroot%{_var}/lib/rpm/filetriggers/ldconfig.filter << EOF
> > >   1019  ^.((/lib|/usr/lib)(64)?/[^/]*\.so\.|/etc/ld.so.conf.d/[^/]*\.conf)
> > >   1020  EOF
> > >   1021  cat > %buildroot%{_var}/lib/rpm/filetriggers/ldconfig.script << EOF
> > >   1022  #!/bin/sh
> > >   1023  ldconfig -X
> > >   1024  EOF
> > >   1025  chmod 755 %buildroot%{_var}/lib/rpm/filetriggers/ldconfig.script
> > 
> > Кстати, при подобном раскладе (если содержать триггер в glibc-core),
> > у пакета glibc-core появится зависимость на sh (а у sh уже есть
> > зависимость на glibc-core).  Впрочем, триггер можно написать на Си...
> 
> В glibc-core уже есть несколько таких скриптов на C.
> А вот если там появится зависимость на @RPMCONFIGDIR@, то будет не очень
> здорово.

Вот как я себе представляю более аккуратную реализацию.

/usr/lib/rpm/0ldconfig.filetrigger
     1	#!/bin/sh
     2	
     3	IFS=
     4	while read -r f; do
     5		case "$f" in
     6			/lib/lib*/*.so* |\
     7			/lib64/lib*/*.so* |\
     8			/usr/lib/lib*/*.so* |\
     9			/usr/lib64/lib*/*.so* )
    10				# false positives
    11				continue ;;
    12			/lib/lib*.so |\
    13			/lib64/lib*.so |\
    14			/usr/lib/lib*.so |\
    15			/usr/lib64/lib*.so )
    16				# maybe soname
    17				if set $f.* && [ -f "$1" ]; then
    18					continue
    19				fi
    20				;;
    21			/lib/lib*.so.* |\
    22			/lib64/lib*.so.* |\
    23			/usr/lib/lib*.so.* |\
    24			/usr/lib64/lib*.so.* )
    25				# soname
    26				;;
    27			/etc/ld.so.conf.d/*.conf)
    28				;;
    29			*) continue ;;
    30		esac
    31		exec /sbin/ldconfig
    32	done

Такой триггер должен кооркетно обрабатывать установку и удаление *-devel
пакетов с симлинками (для них запускать ldconfig не надо).

В принципе можно запаковать такой триггер не в glibc-core, а в rpm.

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

Re: [devel] /etc/ld.so.cache

[Dmitry V. Levin]

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

On Mon, Sep 15, 2008 at 11:11:47AM +0400, Alexey Tourbin wrote:
> On Fri, Sep 12, 2008 at 12:53:29AM +0400, Dmitry V. Levin wrote:
> > > > Кстати, вот как это сделано в Мандриве (glibc-2.8-1.20080520.5mnb2.src.rpm),
> > > > glibc.spec:
> > > >   1015  # automatic ldconfig cache update on rpm installs/removals
> > > >   1016  # (see http://wiki.mandriva.com/en/Rpm_filetriggers)
> > > >   1017  install -d %buildroot%{_var}/lib/rpm/filetriggers
> > > >   1018  cat > %buildroot%{_var}/lib/rpm/filetriggers/ldconfig.filter << EOF
> > > >   1019  ^.((/lib|/usr/lib)(64)?/[^/]*\.so\.|/etc/ld.so.conf.d/[^/]*\.conf)
> > > >   1020  EOF
> > > >   1021  cat > %buildroot%{_var}/lib/rpm/filetriggers/ldconfig.script << EOF
> > > >   1022  #!/bin/sh
> > > >   1023  ldconfig -X
> > > >   1024  EOF
> > > >   1025  chmod 755 %buildroot%{_var}/lib/rpm/filetriggers/ldconfig.script
> > > 
> > > Кстати, при подобном раскладе (если содержать триггер в glibc-core),
> > > у пакета glibc-core появится зависимость на sh (а у sh уже есть
> > > зависимость на glibc-core).  Впрочем, триггер можно написать на Си...
> > 
> > В glibc-core уже есть несколько таких скриптов на C.
> > А вот если там появится зависимость на @RPMCONFIGDIR@, то будет не очень
> > здорово.
> 
> Вот как я себе представляю более аккуратную реализацию.
> 
> /usr/lib/rpm/0ldconfig.filetrigger
>      1	#!/bin/sh
>      2	
>      3	IFS=
>      4	while read -r f; do
>      5		case "$f" in
>      6			/lib/lib*/*.so* |\
>      7			/lib64/lib*/*.so* |\
>      8			/usr/lib/lib*/*.so* |\
>      9			/usr/lib64/lib*/*.so* )
>     10				# false positives
>     11				continue ;;
>     12			/lib/lib*.so |\
>     13			/lib64/lib*.so |\
>     14			/usr/lib/lib*.so |\
>     15			/usr/lib64/lib*.so )
>     16				# maybe soname
>     17				if set $f.* && [ -f "$1" ]; then
>     18					continue
>     19				fi
>     20				;;
>     21			/lib/lib*.so.* |\
>     22			/lib64/lib*.so.* |\
>     23			/usr/lib/lib*.so.* |\
>     24			/usr/lib64/lib*.so.* )
>     25				# soname

Могут возникнуть (раньше были) дополнительные каталоги,
возможно стоит запустить /usr/lib/rpm/dump_ld_config.


-- 
ldv

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

Re: [devel] /etc/ld.so.cache

[Alexey Tourbin]

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

On Mon, Sep 15, 2008 at 02:05:27PM +0400, Dmitry V. Levin wrote:
> > /usr/lib/rpm/0ldconfig.filetrigger
> >      1	#!/bin/sh
> >      2	
> >      3	IFS=
> >      4	while read -r f; do
> >      5		case "$f" in
> >      6			/lib/lib*/*.so* |\
> >      7			/lib64/lib*/*.so* |\
> >      8			/usr/lib/lib*/*.so* |\
> >      9			/usr/lib64/lib*/*.so* )
> >     10				# false positives
> >     11				continue ;;
> >     12			/lib/lib*.so |\
> >     13			/lib64/lib*.so |\
> >     14			/usr/lib/lib*.so |\
> >     15			/usr/lib64/lib*.so )
> >     16				# maybe soname
> >     17				if set $f.* && [ -f "$1" ]; then
> >     18					continue
> >     19				fi
> >     20				;;
> >     21			/lib/lib*.so.* |\
> >     22			/lib64/lib*.so.* |\
> >     23			/usr/lib/lib*.so.* |\
> >     24			/usr/lib64/lib*.so.* )
> >     25				# soname
> 
> Могут возникнуть (раньше были) дополнительные каталоги,
> возможно стоит запустить /usr/lib/rpm/dump_ld_config.

dump_ld_config не документирован, а из исходников не совсем очевидно,
какой у него synopsis и что он должен выводить.

В любом случае, идея понятна: лучше исходить не из фиксированного набора
каталогов, которые перечисляются в шаблонах, а из списка каталогов в
общем виде.

while read -r f; do
	case "$f" in
		/etc/ld.so.conf.d/*.conf)
			exec /sbin/ldconfig
			;;
	esac
	case "${f##*/} in
		lib*.so*) ;;
		*) continue ;;
	esac
	found=
	for dir in $dirs; do
		case "$f" in
			# XXX /usr/lib64/sse2
			"$dir"/*/*) continue ;;
			"$dir"/*) found=1; break ;;
			*) continue ;;
		esac
	done
	[ -n "$found" ] || continue
	case "${f##*/} in
		lib*.so)
			if set "$f".* && [ -f "$1" ]; then
				continue
			fi
			;;
	esac
	exec /sbin/ldconfig
done

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

Re: [devel] /etc/ld.so.cache

[Alexey Tourbin]

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

On Mon, Sep 15, 2008 at 11:11:47AM +0400, Alexey Tourbin wrote:
> /usr/lib/rpm/0ldconfig.filetrigger
>      1	#!/bin/sh
>      2	
>      3	IFS=
>      4	while read -r f; do
>      5		case "$f" in
>      6			/lib/lib*/*.so* |\
>      7			/lib64/lib*/*.so* |\
>      8			/usr/lib/lib*/*.so* |\
>      9			/usr/lib64/lib*/*.so* )
>     10				# false positives
>     11				continue ;;
>     12			/lib/lib*.so |\
>     13			/lib64/lib*.so |\
>     14			/usr/lib/lib*.so |\
>     15			/usr/lib64/lib*.so )
>     16				# maybe soname
>     17				if set $f.* && [ -f "$1" ]; then
>     18					continue
>     19				fi
>     20				;;
>     21			/lib/lib*.so.* |\
>     22			/lib64/lib*.so.* |\
>     23			/usr/lib/lib*.so.* |\
>     24			/usr/lib64/lib*.so.* )
>     25				# soname
>     26				;;
>     27			/etc/ld.so.conf.d/*.conf)
>     28				;;
>     29			*) continue ;;
>     30		esac
>     31		exec /sbin/ldconfig
>     32	done
> 
> Такой триггер должен кооркетно обрабатывать установку и удаление *-devel
> пакетов с симлинками (для них запускать ldconfig не надо).

Однако же ldconfig записывает в кеш в том числе и линковочные
симлинки, название которых не совпадает с soname'ом.

$ ldconfig -p |fgrep libz.
        libz.so.1 (libc6,x86-64) => /lib64/libz.so.1
        libz.so.1 (libc6) => /lib/libz.so.1
        libz.so (libc6,x86-64) => /usr/lib64/libz.so
$ ldconfig -p |fgrep libglib-2
        libglib-2.0.so.0 (libc6,x86-64) => /lib64/libglib-2.0.so.0
        libglib-2.0.so (libc6,x86-64) => /usr/lib64/libglib-2.0.so
$ 

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