Внимательное отношение к эпохе пакета
При разрешении зависимостей, эпоха (Epoch) имеет более важное значение чем версия пакета.
Например если в пакете указать зависимость без эпохи
Requires: qt >= 4.7.4
А в системе установлена версия 4.6.3 первой эпохи
[grin@grinvb i686]$ yum info qt
Loaded plugins: refresh-packagekit, security
Installed Packages
Name : qt
Arch : i686
Epoch : 1
Version : 4.6.3
Release : 1.el6
Size : 35 M
Repo : installed
То, при установки нашего пакета, rpm решит, что 4.6.3 более новая, чем требуемая 4.7.4, следовательно зависимость удовлетворена и можно ставить пакет, что является ошибкой.
Решением будет указать эпоху в зависимости:
Requires: qt >= 1:4.7.4
Аналогично. Если устанавливать пакет qt.4.7.4 ( который собран без указания эпохи ), то пакет не установится, т.к. rpm скажет. что установлен более свежий пакет первой эпохи версии 4.6.3.
Решением будет указать эпоху в spec-файле ( лучше взять равную эпохе установленного пакета):
Epoch : 1
Вообще лучше не использовать тэг Epoch в spec-файлах без явной необходимости.
Порядок выполнения скриптов при апдейте пакета
При апдейте пакета ( без учёта триггеров ) сначала выполняются %pre и %post скрипты нового пакета, а затем %preun и %postun скрипты старого пакета.
Проблема проявляется в случае демона, который надо стартовать после установки, а при удалении сначала надо останавливать демона. Без учёта того, что именно происходит ( удаление пакета, или апгрейд пакета ), при апгрейде получим ситуацию, когда новый пакет запускает установленного демона, а старый пакет сразу же его останавливает.
Если дополнительно создаются/удаляются пользователи ( папки ) - то получается совсем грустная картина.
В руководстве по RPM говорится о том, что rpm при вызове указанных скриптов передаёт им первым параметром ( ${1} )число, которое обозначает текущую ситуацию.
Лучше всего проилюстрировать обработку этого параметра следующим скриптом
case ${1} in
0)
echo "Удаляем последнюю версию пакета";;
1)
echo "Впервые устанавливаем пакет";;
[2-99]*)
echo "Обновляем ранее установленный пакет";;
esac
При разрешении зависимостей, эпоха (Epoch) имеет более важное значение чем версия пакета.
Например если в пакете указать зависимость без эпохи
Requires: qt >= 4.7.4
А в системе установлена версия 4.6.3 первой эпохи
[grin@grinvb i686]$ yum info qt
Loaded plugins: refresh-packagekit, security
Installed Packages
Name : qt
Arch : i686
Epoch : 1
Version : 4.6.3
Release : 1.el6
Size : 35 M
Repo : installed
То, при установки нашего пакета, rpm решит, что 4.6.3 более новая, чем требуемая 4.7.4, следовательно зависимость удовлетворена и можно ставить пакет, что является ошибкой.
Решением будет указать эпоху в зависимости:
Requires: qt >= 1:4.7.4
Аналогично. Если устанавливать пакет qt.4.7.4 ( который собран без указания эпохи ), то пакет не установится, т.к. rpm скажет. что установлен более свежий пакет первой эпохи версии 4.6.3.
Решением будет указать эпоху в spec-файле ( лучше взять равную эпохе установленного пакета):
Epoch : 1
Вообще лучше не использовать тэг Epoch в spec-файлах без явной необходимости.
Порядок выполнения скриптов при апдейте пакета
При апдейте пакета ( без учёта триггеров ) сначала выполняются %pre и %post скрипты нового пакета, а затем %preun и %postun скрипты старого пакета.
Проблема проявляется в случае демона, который надо стартовать после установки, а при удалении сначала надо останавливать демона. Без учёта того, что именно происходит ( удаление пакета, или апгрейд пакета ), при апгрейде получим ситуацию, когда новый пакет запускает установленного демона, а старый пакет сразу же его останавливает.
Если дополнительно создаются/удаляются пользователи ( папки ) - то получается совсем грустная картина.
В руководстве по RPM говорится о том, что rpm при вызове указанных скриптов передаёт им первым параметром ( ${1} )число, которое обозначает текущую ситуацию.
Лучше всего проилюстрировать обработку этого параметра следующим скриптом
case ${1} in
0)
echo "Удаляем последнюю версию пакета";;
1)
echo "Впервые устанавливаем пакет";;
[2-99]*)
echo "Обновляем ранее установленный пакет";;
esac
Комментариев нет:
Отправить комментарий