[devel] Re: [sisyphus] Доигрался...

[devel] Re: [sisyphus] Доигрался...

[Dmitry V. Levin]

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

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.

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

Re: [devel] Re: [sisyphus] Доигрался...

[Ivan Zakharyaschev]

On Tue, 9 Jan 2001, Dmitry V. Levin wrote:

> On Tue, Jan 09, 2001 at 05:36:38PM +0300, Ivan Zakharyaschev wrote:

> > 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 нельзя, он устанавливается в системе много раньше других.

Так это наоборот хорошо: этим гарантируется, что ни один "старый" пакет не
будет заменен без исполнения предназначенного для него trigger'а. После
установки initscripts trigger'ы будут в системе, и в конце обновления
каждого из затронутых пакетов будет исполнен один из них. Нужно только к
уже написанным магическим строчкам добавить проверку на то, происходит ли
просто удаление или обновление пакета (не уверен, что это можно сделать).

> > Дополнение к 3: в соответсвии с packaging HOWTO, учитывая то, что
> этот
> > кусок spec-файла (trigger-script) будет использован многократно,
> нужно
> > создать макрос для него, например %{chkconfigSince:scriptname
> version}.
>
> Тогда уж лучше так:
> %ChkconfigAddSince packagename packageversion scriptname
>
> > Если до этого дойдет дело, то тогда можно попробовать создать и
> макрос
> > более широкого назначения для пакетов, предоставляющих стартовые
> скрипты:
> > %{initscript:name chkconfigSince}.
>
> Не понял.

Я сам только смутно его представляю: который бы делал все то, что
прописывается вручную в spec-файле в связи с установкой init-скрипта:
вызовы chkconfig в postinstall, в preun -- с нужными проверками на
количество пакетов, а также уже описанный chkconfigAddSince. И еще, что
уже совсем на грани фантастики, добавление /etc/rc.d/init.d/scriptname в
секцию %files.

Не знаю, позволяют ли технические возможности такой макрос написать: нужна
возможность "нанизывать" команды в секции %post, %preun (в которых кроме
установки init-скрипта могут совершаться и другие действия, в том числе и
установка второго такого скрипта); можно во избежание этих трудностей
вместо %post и %preun использовать соответствующие triggers -- ограничиния
на их число, наверное, нет. Тогда на каждый init-скрипт по три триггера
(один из которых борется со "старыми" пакетами).

-- 
Best regards,
      Ivan Z.

_______________________________________________
Devel mailing list
Devel@linux.iplabs.ru
http://www.logic.ru/mailman/listinfo/devel

[devel] Re: [devel] Re: [sisyphus] Доигрался...

[Dmitry V. Levin]

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

On Tue, Jan 09, 2001 at 09:45:05PM +0300, Ivan Zakharyaschev wrote:
> > > 4. Запихать все такие триггеры в один пакет, например initscripts или
> > > специально для этого созданный. Тогда spec-файлы отдельных пакетов
> > можно
> > > оставить такими, какими они есть.
> >
> > В initscripts нельзя, он устанавливается в системе много раньше других.
> 
> Так это наоборот хорошо: этим гарантируется, что ни один "старый" пакет не
> будет заменен без исполнения предназначенного для него trigger'а. После
> установки initscripts trigger'ы будут в системе, и в конце обновления
> каждого из затронутых пакетов будет исполнен один из них. Нужно только к
> уже написанным магическим строчкам добавить проверку на то, происходит ли
> просто удаление или обновление пакета (не уверен, что это можно сделать).

Нет.
Когда ставится initscripts, никаких пакетов, на которые может сработать
триггер, нет. Но дело не в этом. Предполагается, что в Sisyphus просто нет
"неправильных" пакетов, в состав которых входят файлы, находящиеся под
управлением chkconfig. Если они еще остались, то это дурное наследие
Mandrake надо просто зафиксить.

> > > Если до этого дойдет дело, то тогда можно попробовать создать и
> > макрос
> > > более широкого назначения для пакетов, предоставляющих стартовые
> > скрипты:
> > > %{initscript:name chkconfigSince}.
> >
> > Не понял.
> 
> Я сам только смутно его представляю: который бы делал все то, что
> прописывается вручную в spec-файле в связи с установкой init-скрипта:
> вызовы chkconfig в postinstall, в preun -- с нужными проверками на
> количество пакетов, а также уже описанный chkconfigAddSince. И еще, что
> уже совсем на грани фантастики, добавление /etc/rc.d/init.d/scriptname в
> секцию %files.
> 
> Не знаю, позволяют ли технические возможности такой макрос написать: нужна
> возможность "нанизывать" команды в секции %post, %preun (в которых кроме
> установки init-скрипта могут совершаться и другие действия, в том числе и
> установка второго такого скрипта); можно во избежание этих трудностей
> вместо %post и %preun использовать соответствующие triggers -- ограничиния
> на их число, наверное, нет. Тогда на каждый init-скрипт по три триггера
> (один из которых борется со "старыми" пакетами).

Это сразу в TODO (точнее говоря, в TOTHINKABOUT) для rpm-4.1 :-)


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.

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