Частое обновление больших программ
Гость 16 мая, 2007 - 19:58
Существует ли какой-либо способ не проводить обновление пакета при выполнении emerge world, если в свежей версии ebuild'а изменился только номер ревизии?
Приведу пример:
Допустим был установлен package-0.0.1-r2, через некоторое время я собираюсь сделать emerge world, а в этот момент уже появился package-0.0.1-r3. Обновляться на него я как раз и не хочу.
Смысл данной затеи в том, что большие программы долго собираются. А в новых ревизиях ebuild'ов обычно бывают только косметические изменения, не связанные с функциональностью программы. И если проводить emerge world достаточно часто, очень не хочется тратить время на практически бесполезную пересборку больших программ.
»
- Для комментирования войдите или зарегистрируйтесь
Лиюо
Лиюо маскируешь этот пакет, либо вывод emerge -pv отправляешь через сед в файл, удаляешь ненужные строки, спереди приписываешь emerge и пускаешь его ставиться.
А как часто вы
А как часто вы обновляетесь? Может проще увеличить цикл обновления до недели-двух?
Еще есть вариант использовать только стабильные пакеты...
Вот при цикле
Вот при цикле обновлния в пару недель как раз такое и получается. Может быть имеет смысл обновляться раз в пару месяцев? Просто обновляться раз в пол года - достаточно утомительное занятие ;-)
Если
Если использовать ccache собирается быстрее. Конечно если и в самом деле косметические изменения.
как отказаться
как отказаться от сборки
Резюме -r1 к
Резюме
-r1 к пакету означает новый релиз на старом сурсе. Возможны критические фиксы. Уж ежели взялись обновлять -отказываться имхо не стоит. Вообще появление новой буковки к версии наводит на мысль что в системе на настоящий момент работает полное....
ccache, как было оговорено, рулит нипадеццки. Особенно на объемных сурсах, когда время поиска в кеше значительно превышает скорость сборки. На мелких сурсах (и большом объеме кэша) - никто не знает.
distcc при должной настройке (имхо не очень тривиальной) спасает отцов русской демократии. Правда для этого надо иметь несколько линуксбоксов.
Не хочешь - не делай. Зафиксируй пакет в /etc/portage/package.mask ИМХО не очень хорошо. Бо за этим придется следить руками, а мы ведь не для этого ставим линукс.
ЗЫ
Похоже для гентушников обновление становится навязчивой идеей. Это понятно - ребята молодые,трудолюбивые. Любят ходить по граблям. Надо как нить открыть тему "Почему не стоит обновлять систему каждый день?" или "От чего пиво лучше Gentoo?". На gentoo.org есть раздельчик по секурити фиксам. Фиксить надо те пакеты, что в наличии и наружу смотрят. Это работа админа. Получается не так много. Раз в году, после очередного и не однодневного тестирования изменений можно и целиком обновиться. Все остальное имхо для тех кто не любит пиво.
> "Почему не
> "Почему не стоит обновлять систему каждый день?"
Почему не стоит?
Засунул в крон скрипт обновления с уведомлением по почте или жабберу и успокоился.
Кстати, хочу напомнить, что для желающих увеличить цикл обновления всей системы, но не желающих уменьшать из-за этого безопасность системы, есть в составе app-portage/gentoolkit скрипт glsa-check.
сорри за тупой
сорри за тупой вопрос, а где про него можно почитать побольше, чем дает ман?
>>Почему не
>>Почему не стоит?
>>Засунул в крон скрипт обновления с уведомлением по почте или жабберу и успокоился.
И что? Реално работает? В таком случае у меня целая куча вопросов:
Как автоматом по крону обойти смену функции хеша паролей в мускуле, а то у меня половина сайтов и бакула в корку упало (пишет типа юзер пассворд - инвалид)?
Как ведет себя сетевой сервис, у которого старый конфиг стал невалидным при обновлении десмона, а то мой эфтипишник полчаса лежал пока я манов курил?
Что делает ебилд постгри с emerge -e world при нахождении по определенному пути старой версии базы данных?
Что вы будете говорить руководству при автоматическом развертывании, к примеру, опенофиса, который гробит юзеровские вордовые и оооочень как бы необходимые файлики?
PS
Крон работает бесплатно. Админу надо платить.И несмотря на то, что шедуллеров под каждую ось полно каждая приличная контора имеет СА в штате. К чему бы это? Это потому что апдейт - работа, и очень серезная. Закачка, фиксация состояния, тестирование, отработка технологии апдейта и отката назад (желательно на подопытных мышках)
реально
реально работает.
Во первых, как ты думаешь, зочем это я нопейсал:
"с уведомлением по почте или жабберу"
а? (:
Во вторых, когда я смотрю в зеркало, я не вижу в отражении идиота постоянно и целиком обновляющего серверную систему. А ты?
Иначе на кой ха эр люди писали glsa-check?
Re: > "Почему не
скрипт в студию
Что в студию то?
Что в студию то? Написано же
Как раз я
Как раз я совершенно не хочу обновляться часто. Но если обновляться раз в пол года, обновление превращается в ад. Сначала надо переключиться на новый профиль (если он появился), потом проверить, собирается ли обновляться toolchain, потом разгрести блокирующие пакеты, потом запустить процесс обновления (кстати далеко не факт, что с первого раза все успешно соберется), а потом вполне возможно придется править много конфигурационных файлов. В итоге, если все пункты успешно выполнены, получаем систему, которая может местами работать не так, как хотелось бы. А быстро понять в каком месте проблема бывает достаточно сложно, ведь обновлялось практически все. Если же обновляться почаще, объем ручной работы бывает поменьше и соответственно если что-то перестает работать, легче понять из-за чего это произошло.
Профиль менять -- это сурово
Ибо там запросто набор USE-флагов измениться может. А это -- гемор. Базовые вещи типа gcc-компилятора, glibc, baselayout -- лучше маскировать от изменений и выполнять вручную. Даже upgrade-пакетов -- и то лучше делать по необходимости (когда нужна новая функциональность). Прежде чем делать какой-то upgrade (хоть portage-data), лучше сделать backup. И вообще для отслеживания новинок лучше иметь вторую (экспериментальную) систему