On Tue, Jan 09, 2001 at 05:36:38PM +0300, Ivan Zakharyaschev wrote:
> >   В общем, обновил initscripts и еще кучу пакетов.
> 
> >   После этого система не перегружается. Видно, что не стартует
> >   portmap и другие сервисы. После загрузки у меня стоял запуск
> >   Иксов. Теперь просто мигает экраном и ничего не происходит.
> 
> Чтобы вновь запускались нужные сервисы при загрузке, придется заново их
> включить вручную, например:
> 
> $ chkconfig --add syslog
> $ chkconfig --add portmap
> 
> и так же с любым другим понравившимся скриптом из /etc/rc.d/init.d/.
> Или то же самое наверняка можно сделать из меню: linuxconf, drakxconf...
> 
> О возможностях более тонкого управления набором стартовых скриптов -- man
> chkconfig.
> 
> syslog и, вероятно, portmap не стартуют вот почему:
> 
> Старые пакеты с ними (из Mdk 7.0) напрямую ставили нужные ссылки в
> /etc/rc.d/rc?.d/ (файлы-ссылки входили в состав пакетов), тут можно
> увидеть некоторые из них:
> 
> $ rpm -qf `rpm -qal | grep '/etc/rc\.d/rc.\.d/.*'` | sort -u
> apache_rus-common-1.3.12_PL29.4-ipl7mdk
> initscripts-5.49-ipl4mdk
> lpr-0.48-1mdk
> netkit-base-0.11-15mdk
> portmap-4.0-8mdk
> 
> (syslog я уже обновил, он тоже после этого не запускался)
> 
> А новые пакеты для этой цели используют систему систему управления этими
> сервисами -- chkconfig.
> 
> Обновление пакета идет по схеме:
> 
> 1. установка нового
> 2. удаление старого
> 
> Поэтому при обновлении такого пакета на этапе 1 вызывается chkconfig
> --add, что оказывается совершненно бесполезным из-за того, что на этапе 2
> установленные chkconfig'ом ссылки удаляются как принадлежащие старому
> пакету и не принадлежащие новому.
> 
> Могу предложить несколько способов борьбы с этим при создании пакетов:
> 
> 1. закрыть на это глаза

Я так и сделал ввиду того, что эта проблема не самого Сизифа, а перехода н
него путем partial update.

> 2. в новых пакетах указывать эти ссылки из /etc/rc.d/rc?.d/ в секции
> %files с директивой %ghost или чем-нибудь в этом роде (по моему, это
> плохой способ: все преимущества использования chkconfig теряются)

От этого варианта я отказался.

> 3. Проописать в новом пакете соответсвующий trigger на старый пакет. Вот
> так это сделано в console-tools из Сизифа:
> 
> %triggerpostun -- console-tools < 0.2.3-ipl1mdk
> /sbin/chkconfig --add keytable || echo "chkconfig failed adding keytable:
> add it manually if you need"
> 
> (он-то исполнится после всего, т.е. после этапа 2)
> 
> Недостаток в том, что загромождается spec-файл пакета.

Конечно, добавить магические строки типа
%triggerpostun -- %name < %version-%release
/sbin/chkconfig --add %name ||:
не так уж и сложно.

Просто поезд уже ушел, а у меня неправильных пакетов уже давно нет в
системе. Не знаю, стоит ли это делать...

> 4. Запихать все такие триггеры в один пакет, например initscripts или
> специально для этого созданный. Тогда spec-файлы отдельных пакетов можно
> оставить такими, какими они есть.

В initscripts нельзя, он устанавливается в системе много раньше других.

> Дополнение к 3: в соответсвии с packaging HOWTO, учитывая то, что этот
> кусок spec-файла (trigger-script) будет использован многократно, нужно
> создать макрос для него, например %{chkconfigSince:scriptname version}.

Тогда уж лучше так:
%ChkconfigAddSince packagename packageversion scriptname

> Если до этого дойдет дело, то тогда можно попробовать создать и макрос
> более широкого назначения для пакетов, предоставляющих стартовые скрипты:
> %{initscript:name chkconfigSince}.

Не понял.


Regards,
	Dmitry

+-------------------------------------------------------------------------+
Dmitry V. Levin     mailto://ldv@fandra.org
Software Engineer   PGP pubkey http://www.fandra.org/users/ldv/pgpkeys.html
IPLabs Linux Team   http://linux.iplabs.ru
Fandra Project      http://www.fandra.org
+-------------------------------------------------------------------------+
UNIX is user friendly. It's just very selective about who its friends are.