Слежение за размаскированными версиями программ
Почитала, что можно делать размаскировку, но что это не есть всегда хорошо. Хорошо.
Вопрос такого плана. Как уследить выход новой версии незамаскированного пакета, если номер такой версии через время станет выше то, что когда-то была размаскирована?
Пример:
<=dev-libs/glib-2.18.1 ~amd64
Версия glib 2.18.1 была замаскирована и я ее размаскировала, но так, что бы не ставилось ничего выше 2.18.1. glib, как пример. Не будем зацикливаться почему и зачем. пусть, будет другой пакет. неважно.
Теперь. Через какое-то время, версия 2.18.1 размаскировывается и, более того, размаскировываются версии>2.18.1. При обновлении/установке какого-либо софта никакой ругани, что не хватает >glib-2.18.1. Ведь, такие случаи могут быть. И я, наивно полагая, что все гуд, курю бамбук.
Не следить же за каждой /var/db/pkg/meta/package/"версией такой темы", вручную просматривая их. Этож жесть|
Есть ли цивилизованный подход у такого момента. Знает ли кто.
Спасибо.
- Для комментирования войдите или зарегистрируйтесь
А зачем следить? Либо
А зачем следить? Либо регулярно обновлять мир, тогда glibc подтянутся, либо не париться по поводу обновлений и обходиться старой версией.
Конкретный же ответ на вопрос: синхронизация с помощью eix-sync (app-portage/eix)
Текстовый редактор vi имеет два режима работы: в первом он пищит, а во втором — всё портит.
Хороший вопрос!
Вы действительно правильно размаскировываете! ;-) Аналогично я перестраховываюсь даже в package.keywords, причём даже более жёстко, т.е. "=atom". Теперь любое обновление полностью под нашим контролем. Обратимся к логике portage... После синхронизации дерева portage и попытки обновить систему, portage норовит инсталлировать максимально новую версию из доступных. Если когда-то я размаскировал пакет "A" (пусть даже просто тестовый), но он прекрасно работал, это не значит, что и следующая тестовая версия будет меня устраивать.
Теперь обновление после eix-sync выполняется сложнее. Сначала для каждого атома, прописанного в portage.{keywords,unmask} выполняется проверка, не вышло ли чего нового: ls /usr/portage/${atom}/...? Но руками обновить portage.{keywords,unmask} явно недостаточно. Потому что если новый пакет "A" меня не устроит, я вынужден буду откатиться на предыдущую версию. Причём обнаружить проблему можно не сразу, а иногда лишь поработав какое-то время. Поэтому я перед обновлением делаю копию portage.{keywords,unmask} либо просто отдельных строчек в них в виде комментариев.
ИМХО, написать скрипт или использовать нечто вроде autounmask можно, но это будет себе дороже. В этом случае система уйдёт из под нашего контроля. Поэтому только такой алгоритм - описанный выше. Единственное, можно написать скрипт, который будет анализировать, сохранять portage.{keywords,unmask}, предлагать новые версии размаскированных (или зафиксированных тестовых) пакетов, если таковые вышли...
А eix-test-obsolete вам не
А eix-test-obsolete вам не поможет?
Я ♥ Gentoo & Funtoo
нужно всеголиш не
нужно всеголиш не <= а просто = ставить, тогда будет разваскирована только одна версия пакета, и когда выйдет следующая немаскированная версия система её увидит
Мнэ-э-э... А что, если
Мнэ-э-э... А что, если размаскировать через <=, то система не увидит?
Лично я размаскировываю до следующей мажорной версии. Например, надо поставить dev-python/sip-4.7.8 — размаскировываю dev-python/sip-4.8.0. С расчётом на то, что минорные обновления ничего не поломают, а важные тараканы могут быть прибиты.
Текстовый редактор vi имеет два режима работы: в первом он пищит, а во втором — всё портит.
Размаскируй как
Размаскируй как "dev-libs/glib ~amd64" и будут обновления показываться стабильные и нестабильные.
С "=dev-libs/glib-2.18.1 ~amd64" тоже обновления будут, только если стабильная версия появится версии выше 2.18.1.
Запись "<=" используется редко.
0 0 * * * /usr/bin/eix-sync
0 0 * * * /usr/bin/eix-sync |grep -e '==' -e '<<' -e '\ >>\ ' |sed 's/(.*)//' - у меня сделано. На почту приходят сообщения типа:
[>] == dev-python/qscintilla-python : Python bindings for Qscintilla
[N] >> app-text/mht-rip : convert mht/mhtml files to something usable
Можно под себя отредактировать.