* [devel] posttrans filetriggers [2]
@ 2008-09-08 9:51 Alexey Tourbin
2008-09-08 12:07 ` Igor Vlasenko
2008-09-08 13:49 ` [devel] libgtk+2 Dmitry V. Levin
0 siblings, 2 replies; 29+ messages in thread
From: Alexey Tourbin @ 2008-09-08 9:51 UTC (permalink / raw)
To: devel
[-- 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 --]
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [devel] posttrans filetriggers [2]
2008-09-08 9:51 [devel] posttrans filetriggers [2] Alexey Tourbin
@ 2008-09-08 12:07 ` Igor Vlasenko
2008-09-08 13:49 ` [devel] libgtk+2 Dmitry V. Levin
1 sibling, 0 replies; 29+ messages in thread
From: Igor Vlasenko @ 2008-09-08 12:07 UTC (permalink / raw)
To: ALT Linux Team development discussions
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
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [devel] libgtk+2
2008-09-08 9:51 [devel] posttrans filetriggers [2] Alexey Tourbin
2008-09-08 12:07 ` Igor Vlasenko
@ 2008-09-08 13:49 ` Dmitry V. Levin
2008-09-08 13:55 ` Alexey Rusakov
` (2 more replies)
1 sibling, 3 replies; 29+ messages in thread
From: Dmitry V. Levin @ 2008-09-08 13:49 UTC (permalink / raw)
To: ALT Devel discussion list
[-- 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 --]
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [devel] libgtk+2
2008-09-08 13:49 ` [devel] libgtk+2 Dmitry V. Levin
@ 2008-09-08 13:55 ` Alexey Rusakov
2008-09-08 14:18 ` Yuri N. Sedunov
2008-09-11 19:25 ` [devel] /etc/ld.so.cache Alexey Tourbin
2 siblings, 0 replies; 29+ messages in thread
From: Alexey Rusakov @ 2008-09-08 13:55 UTC (permalink / raw)
To: ALT Linux Team development discussions
[-- 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 --]
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [devel] libgtk+2
2008-09-08 13:49 ` [devel] libgtk+2 Dmitry V. Levin
2008-09-08 13:55 ` Alexey Rusakov
@ 2008-09-08 14:18 ` Yuri N. Sedunov
2008-09-08 14:23 ` Dmitry V. Levin
2008-09-11 19:25 ` [devel] /etc/ld.so.cache Alexey Tourbin
2 siblings, 1 reply; 29+ messages in thread
From: Yuri N. Sedunov @ 2008-09-08 14:18 UTC (permalink / raw)
To: ALT Linux Team development discussions
В Пнд, 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."
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [devel] libgtk+2
2008-09-08 14:18 ` Yuri N. Sedunov
@ 2008-09-08 14:23 ` Dmitry V. Levin
2008-09-08 14:42 ` Yuri N. Sedunov
0 siblings, 1 reply; 29+ messages in thread
From: Dmitry V. Levin @ 2008-09-08 14:23 UTC (permalink / raw)
To: ALT Linux Team development discussions
[-- 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 --]
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [devel] libgtk+2
2008-09-08 14:23 ` Dmitry V. Levin
@ 2008-09-08 14:42 ` Yuri N. Sedunov
2008-09-08 14:46 ` Dmitry V. Levin
0 siblings, 1 reply; 29+ messages in thread
From: Yuri N. Sedunov @ 2008-09-08 14:42 UTC (permalink / raw)
To: ALT Linux Team development discussions
В Пнд, 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?
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [devel] libgtk+2
2008-09-08 14:42 ` Yuri N. Sedunov
@ 2008-09-08 14:46 ` Dmitry V. Levin
2008-09-08 15:15 ` Yuri N. Sedunov
0 siblings, 1 reply; 29+ messages in thread
From: Dmitry V. Levin @ 2008-09-08 14:46 UTC (permalink / raw)
To: ALT Linux Team development discussions
[-- 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 --]
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [devel] libgtk+2
2008-09-08 14:46 ` Dmitry V. Levin
@ 2008-09-08 15:15 ` Yuri N. Sedunov
2008-09-08 15:21 ` Mikhail Gusarov
` (3 more replies)
0 siblings, 4 replies; 29+ messages in thread
From: Yuri N. Sedunov @ 2008-09-08 15:15 UTC (permalink / raw)
To: ALT Linux Team development discussions
В Пнд, 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
совсем.
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [devel] libgtk+2
2008-09-08 15:15 ` Yuri N. Sedunov
@ 2008-09-08 15:21 ` Mikhail Gusarov
2008-09-08 15:24 ` Andrey Rahmatullin
` (2 subsequent siblings)
3 siblings, 0 replies; 29+ messages in thread
From: Mikhail Gusarov @ 2008-09-08 15:21 UTC (permalink / raw)
To: ALT Linux Team development discussions
[-- 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 --]
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [devel] libgtk+2
2008-09-08 15:15 ` Yuri N. Sedunov
2008-09-08 15:21 ` Mikhail Gusarov
@ 2008-09-08 15:24 ` Andrey Rahmatullin
2008-09-08 15:26 ` Alexey Rusakov
2008-09-08 15:27 ` Dmitry V. Levin
3 siblings, 0 replies; 29+ messages in thread
From: Andrey Rahmatullin @ 2008-09-08 15:24 UTC (permalink / raw)
To: devel
[-- 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 --]
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [devel] libgtk+2
2008-09-08 15:15 ` Yuri N. Sedunov
2008-09-08 15:21 ` Mikhail Gusarov
2008-09-08 15:24 ` Andrey Rahmatullin
@ 2008-09-08 15:26 ` Alexey Rusakov
2008-09-08 15:41 ` Yuri N. Sedunov
2008-09-08 15:27 ` Dmitry V. Levin
3 siblings, 1 reply; 29+ messages in thread
From: Alexey Rusakov @ 2008-09-08 15:26 UTC (permalink / raw)
To: ALT Linux Team development discussions
[-- 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 --]
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [devel] libgtk+2
2008-09-08 15:26 ` Alexey Rusakov
@ 2008-09-08 15:41 ` Yuri N. Sedunov
2008-09-08 15:46 ` Dmitry V. Levin
0 siblings, 1 reply; 29+ messages in thread
From: Yuri N. Sedunov @ 2008-09-08 15:41 UTC (permalink / raw)
To: ALT Linux Team development discussions
В Пнд, 08/09/2008 в 19:26 +0400, Alexey Rusakov пишет:
<skip>
> > Это предложение равносильно тому, чтобы не использовать icon-theme.cache
> > совсем.
> Не равносильно. Если иконка существует в кэше, она оттуда будет (быстро)
> взята. А вот если её нет...
Именно потому и равносильно, что вероятность оказаться в кеше в нашей
системе у конкретной иконки невелика.
> В принципе, если воспринимать icon-theme.cache не как кэш, а poor-man's
> прокси-сервер, поставляющий иконки, то его действительно нужно обновлять
> при каждой установке иконок и брать иконки только оттуда.
Именно, надо обновлять icon-theme.cache. Вопрос лишь в средствах.
> Либо патчить
> Gtk+ на предмет того, чтобы она обращалась с ним действительно как с
> кэшом. Но тогда, извините, нужно ещё, чтобы Gtk+ кэшировала найденные
> иконки. А то иначе какой-то однобокий кэш получается.
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [devel] libgtk+2
2008-09-08 15:41 ` Yuri N. Sedunov
@ 2008-09-08 15:46 ` Dmitry V. Levin
2008-09-08 15:54 ` Yuri N. Sedunov
0 siblings, 1 reply; 29+ messages in thread
From: Dmitry V. Levin @ 2008-09-08 15:46 UTC (permalink / raw)
To: ALT Linux Team development discussions
[-- 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 --]
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [devel] libgtk+2
2008-09-08 15:46 ` Dmitry V. Levin
@ 2008-09-08 15:54 ` Yuri N. Sedunov
2008-09-09 10:05 ` Sergey V Turchin
0 siblings, 1 reply; 29+ messages in thread
From: Yuri N. Sedunov @ 2008-09-08 15:54 UTC (permalink / raw)
To: ALT Linux Team development discussions
В Пнд, 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 и его актуальность
обеспечена системными средствами. Предлагается и на неживых системах
решить вопрос системно без потери производительности.
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [devel] libgtk+2
2008-09-08 15:15 ` Yuri N. Sedunov
` (2 preceding siblings ...)
2008-09-08 15:26 ` Alexey Rusakov
@ 2008-09-08 15:27 ` Dmitry V. Levin
3 siblings, 0 replies; 29+ messages in thread
From: Dmitry V. Levin @ 2008-09-08 15:27 UTC (permalink / raw)
To: ALT Linux Team development discussions
[-- 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 --]
^ permalink raw reply [flat|nested] 29+ messages in thread
* [devel] /etc/ld.so.cache
2008-09-08 13:49 ` [devel] libgtk+2 Dmitry V. Levin
2008-09-08 13:55 ` Alexey Rusakov
2008-09-08 14:18 ` Yuri N. Sedunov
@ 2008-09-11 19:25 ` Alexey Tourbin
2008-09-11 19:58 ` Dmitry V. Levin
2 siblings, 1 reply; 29+ messages in thread
From: Alexey Tourbin @ 2008-09-11 19:25 UTC (permalink / raw)
To: ALT Devel discussion list
[-- 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 --]
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [devel] /etc/ld.so.cache
2008-09-11 19:25 ` [devel] /etc/ld.so.cache Alexey Tourbin
@ 2008-09-11 19:58 ` Dmitry V. Levin
2008-09-11 20:16 ` Alexey Tourbin
0 siblings, 1 reply; 29+ messages in thread
From: Dmitry V. Levin @ 2008-09-11 19:58 UTC (permalink / raw)
To: ALT Devel discussion list
[-- 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 --]
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [devel] /etc/ld.so.cache
2008-09-11 19:58 ` Dmitry V. Levin
@ 2008-09-11 20:16 ` Alexey Tourbin
2008-09-11 20:20 ` Dmitry V. Levin
0 siblings, 1 reply; 29+ messages in thread
From: Alexey Tourbin @ 2008-09-11 20:16 UTC (permalink / raw)
To: ALT Devel discussion list
[-- 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 --]
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [devel] /etc/ld.so.cache
2008-09-11 20:16 ` Alexey Tourbin
@ 2008-09-11 20:20 ` Dmitry V. Levin
2008-09-11 20:38 ` Alexey Tourbin
0 siblings, 1 reply; 29+ messages in thread
From: Dmitry V. Levin @ 2008-09-11 20:20 UTC (permalink / raw)
To: ALT Devel discussion list
[-- 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 --]
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [devel] /etc/ld.so.cache
2008-09-11 20:20 ` Dmitry V. Levin
@ 2008-09-11 20:38 ` Alexey Tourbin
2008-09-11 20:48 ` Alexey Tourbin
2008-09-11 20:50 ` Dmitry V. Levin
0 siblings, 2 replies; 29+ messages in thread
From: Alexey Tourbin @ 2008-09-11 20:38 UTC (permalink / raw)
To: ALT Devel discussion list
[-- 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 --]
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [devel] /etc/ld.so.cache
2008-09-11 20:38 ` Alexey Tourbin
@ 2008-09-11 20:48 ` Alexey Tourbin
2008-09-11 20:53 ` Dmitry V. Levin
2008-09-11 20:50 ` Dmitry V. Levin
1 sibling, 1 reply; 29+ messages in thread
From: Alexey Tourbin @ 2008-09-11 20:48 UTC (permalink / raw)
To: ALT Devel discussion list
[-- 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 --]
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [devel] /etc/ld.so.cache
2008-09-11 20:48 ` Alexey Tourbin
@ 2008-09-11 20:53 ` Dmitry V. Levin
2008-09-15 7:11 ` Alexey Tourbin
0 siblings, 1 reply; 29+ messages in thread
From: Dmitry V. Levin @ 2008-09-11 20:53 UTC (permalink / raw)
To: ALT Devel discussion list
[-- 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 --]
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [devel] /etc/ld.so.cache
2008-09-11 20:53 ` Dmitry V. Levin
@ 2008-09-15 7:11 ` Alexey Tourbin
2008-09-15 10:05 ` Dmitry V. Levin
2008-10-06 7:04 ` Alexey Tourbin
0 siblings, 2 replies; 29+ messages in thread
From: Alexey Tourbin @ 2008-09-15 7:11 UTC (permalink / raw)
To: ALT Devel discussion list
[-- 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 --]
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [devel] /etc/ld.so.cache
2008-09-15 7:11 ` Alexey Tourbin
@ 2008-09-15 10:05 ` Dmitry V. Levin
2008-09-19 7:02 ` Alexey Tourbin
2008-10-06 7:04 ` Alexey Tourbin
1 sibling, 1 reply; 29+ messages in thread
From: Dmitry V. Levin @ 2008-09-15 10:05 UTC (permalink / raw)
To: ALT Devel discussion list
[-- 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 --]
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [devel] /etc/ld.so.cache
2008-09-15 10:05 ` Dmitry V. Levin
@ 2008-09-19 7:02 ` Alexey Tourbin
0 siblings, 0 replies; 29+ messages in thread
From: Alexey Tourbin @ 2008-09-19 7:02 UTC (permalink / raw)
To: ALT Devel discussion list
[-- 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 --]
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [devel] /etc/ld.so.cache
2008-09-15 7:11 ` Alexey Tourbin
2008-09-15 10:05 ` Dmitry V. Levin
@ 2008-10-06 7:04 ` Alexey Tourbin
1 sibling, 0 replies; 29+ messages in thread
From: Alexey Tourbin @ 2008-10-06 7:04 UTC (permalink / raw)
To: ALT Devel discussion list
[-- 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 --]
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [devel] /etc/ld.so.cache
2008-09-11 20:38 ` Alexey Tourbin
2008-09-11 20:48 ` Alexey Tourbin
@ 2008-09-11 20:50 ` Dmitry V. Levin
1 sibling, 0 replies; 29+ messages in thread
From: Dmitry V. Levin @ 2008-09-11 20:50 UTC (permalink / raw)
To: ALT Devel discussion list
[-- 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 --]
^ permalink raw reply [flat|nested] 29+ messages in thread
end of thread, other threads:[~2008-10-06 7:04 UTC | newest]
Thread overview: 29+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-09-08 9:51 [devel] posttrans filetriggers [2] Alexey Tourbin
2008-09-08 12:07 ` Igor Vlasenko
2008-09-08 13:49 ` [devel] libgtk+2 Dmitry V. Levin
2008-09-08 13:55 ` Alexey Rusakov
2008-09-08 14:18 ` Yuri N. Sedunov
2008-09-08 14:23 ` Dmitry V. Levin
2008-09-08 14:42 ` Yuri N. Sedunov
2008-09-08 14:46 ` Dmitry V. Levin
2008-09-08 15:15 ` Yuri N. Sedunov
2008-09-08 15:21 ` Mikhail Gusarov
2008-09-08 15:24 ` Andrey Rahmatullin
2008-09-08 15:26 ` Alexey Rusakov
2008-09-08 15:41 ` Yuri N. Sedunov
2008-09-08 15:46 ` Dmitry V. Levin
2008-09-08 15:54 ` Yuri N. Sedunov
2008-09-09 10:05 ` Sergey V Turchin
2008-09-08 15:27 ` Dmitry V. Levin
2008-09-11 19:25 ` [devel] /etc/ld.so.cache Alexey Tourbin
2008-09-11 19:58 ` Dmitry V. Levin
2008-09-11 20:16 ` Alexey Tourbin
2008-09-11 20:20 ` Dmitry V. Levin
2008-09-11 20:38 ` Alexey Tourbin
2008-09-11 20:48 ` Alexey Tourbin
2008-09-11 20:53 ` Dmitry V. Levin
2008-09-15 7:11 ` Alexey Tourbin
2008-09-15 10:05 ` Dmitry V. Levin
2008-09-19 7:02 ` Alexey Tourbin
2008-10-06 7:04 ` Alexey Tourbin
2008-09-11 20:50 ` Dmitry V. Levin
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