В ходе разборок после массового обновления пакетов откатил glib2 с 2.16.1-alt1 на 2.15.6-alt1. При этом обнаружил, что перестал работать mc (возможно, не только он), жалуясь на ненаденность библиотеки, к которой слинкован. Выяснилось, что симлинки в каталоге /lib/, принадлежащие пакету, битые: указывают не на *.so.0.1506*, а на *.so.0.1600* (rpm -V glib2 подтвердил, выведа 8 строки с модификатором "L"). После ручного разруливания работоспособность mc восстановилась. Не знаю, кто именно виноват - новый glib2 или старый, но, надеюсь, в будущих версиях это будет учтено и поправлено (если ещё не). Steps to Reproduce: 1.apt-get install glib2=2.16.1-alt1 2.apt-get install glib2=2.15.6-alt1 3.mc Actual Results: lib not found Expected Results: mc runs
Эта проблема относится не к glib2, а к rpm, я подозреваю. Точно такую же беду я схлопотал на откате gnome-panel, симлинки повисли в воздухе.
Проблема даже не в rpm, а в /sbin/postun_ldconfig из пакета glibc-core. ldconfig в этом случае вызывается только если пакет удаляется. Предыдущий вызов ldconfig из %post проходит при наличии двух версий библиотеки и симлинк проставляется на бОльший SONAME. В случае когда SONAME уменьшается в пакете надо рисовать триггеры. Когда откат н астарый пакет идёт руками, надо вызывать ldconfig вручную. Это такая фича. P.S. В пакетах xscreensaver и vim-* я решил эту проблему, когда "post" скрипты запускаются после удаления файлов старой версии пакета, но с библиотеками такой хак не прокатит.
Можно как-то автоматизировать и стандартизировать процедуру "починки"? ldv?
(In reply to comment #3) > Можно как-то автоматизировать и стандартизировать процедуру "починки"? ldv? Можно выкинуть эту оптимизацию из postun_ldconfig, тогда пи откатах библиотек не надо будет вызывать ldconfig вручную, ценой двукратного увеличения числа вызовов ldconfig при любом обновлении библиотек.
Не надо нам такой цены.
(In reply to comment #5) > Не надо нам такой цены. Угу... возможно, разумным хаком могло бы быть откладывание в той ветке оптимизации, где ldconfig не выполняется, его на одноразовую post mortem часть?
ldv: можно так сделать, как Миша предлагает? А то в Сизифе иногда либы откатывать надо :-)
С внедрением в librpm posttrans filetriggers появился ещё один вариант решения проблемы, который мне кажется более предпочтительным: Превратить post_ldconfig и postun_ldconfig в ссылки на ldconfig, а в самом ldconfig сделать проверку на RPM_INSTALL_NAME, т.е. просто деактивировать ldconfig, запускаемый скриптами пакетов.
Fixed in glibc-core-2.9-alt1 by disabling all kinds of ldconfig when RPM_INSTALL_NAME is set.
Угу, filetriggers rulez.
