[арч] [и гентушникам тоже] пересборка : тяжела жизнь грызущих кактус!

1. Разок в недельку emerge -avuDN world, хотя последний месяц что-то я забил на это, надо бы обновить будет на днях...

2. Маскирую, размаскировываю...

Каждый день вечером у меня (как, наверное, у многих здесь) запускается полное автообновлени

Не дай мне аллах каждый вечер мир пересобирать, это ж времени на лор не останется! =)

> Разок в недельку emerge -avuDN world

Маскирую

Не дай мне аллах каждый вечер мир пересобирать

т.е. написанное выше может оказаться актуальным и для гентушников :Ъ
а я надеялся что в Самом Лучшем Сорс Дистре такие детские проблемы еще век назад решили, и не придется придумывать велосипедов...

Кстати, я весь пост не осилил прочитать... =)

На самом деле проблемы могут возникнуть только тогда, когда не обновлялся давно. Если постоянно этим заниматься, то при полной пересборке все пучком. Да и есть же emerge -p, где можно посмотреть все возможные проблемы и несовместимости.

И, да, я имел ввиду, что он долго пересобирается, а я же люблю лицезреть консоль с выхлопом емерже во время пересборки, так что время будет убиваться на просто сидение и погружение в выхлоп емерже...

Тайд или кипячение.

> у вас ведь полное обновление системы должно занимать больше суток?!!!

так вот оно что: все думают, будто гентушники постоянно заново собирают все пакеты! На самом деле те пакеты, которые уже собраны, конпелять заново не нужно. Вот и вся недолга.

> На самом деле те пакеты, которые уже собраны, конпелять заново не нужно.

учитывая что ветки nightly-stable (или trunk) обновляется каждый день, то и пакеты которые билдаются с них тоже меняются каждый день. Таким образом, если система синхронизована с последними обновлениями в репозиториях, то пакетов «которые уже собраны» не так уж и много. Разве что самая базовая система.

> а я же люблю лицезреть консоль с выхлопом емерже

кстати, это годная мысль! Вместе с пересобранными пакетами нужно выкладывать не только скрипты которые их собирали (как в абсе), но еще и выхлоп емерже/yaourt/packer и прочее gcc

>т.е. написанное выше может оказаться актуальным и для гентушников :Ъ

Погугли, что такое USE-флаги, тогда сам поймешь, что глупость сморозил.

>nightly-stable (или trunk)

«Ну не может быть человек настолько сексуально неудовлетворен» (ц)

> учитывая что ветки nightly-stable (или trunk) обновляется каждый день

Гентушники тут не при чём, хочу тебе сказать. Так крепко на транке сидят только на голову больные. У нормального гентушника только максимум десяток программ из транка есть, и он их раз в неделю обновляет вместе с остальными обновлениями. То, что ты описал в топике к гентушникам никакого отношения не имеет, это LFS головного мозга в терминальной стадии.

> Погугли, что такое USE-флаги

я не про use-флаги, а про distributed continuous integration.

>1) как вы делаете обновления?

emerge -auvDN world system
или
emerge -auvDN @world @system
в зависимости от машины и версии портежа :)

...

А так - сейчас обычно от раза в день до раза в неделю вручную. До того, как сдохла железка на сервере airbase.ru, там автообновление было еженочное автоматическое в течении лет трёх, наверное.

Есть ли практика Continuous Integration

Непонятен вопрос.

Как вы вообще так живете: у вас ведь полное обновление системы должно занимать больше суток?!!!

А зачем обновлять всё? Обычно в системе есть масса пакетов, которые и больше года не обновляются. Правда я, на всякий случай, сейчас время от времени прогоняю автоматическую пересборку старых пакетов (сейчас временно поставил предельный срок пакета без пересборки в 200 суток).

А обычное обновление занимает, в зависимости от производительности и количества обновления от нескольких минут до нескольких часов. В среднем же по больнице, наверное, минут 15-20 выходит.

2) как вы разруливаете опциональные зависимости и приоритеты зависимостей?

Так в портеже всё прописано. Очень редко, и в основном на тестовых версиях, возникают конфликты, когда один обновляющийся пакет хочет по зависимостям новую версию другого, а что-то установленное в системе - старую. Такие ситуации можно до какого-то времени игнорировать (конфликтное обновление просто не произойдёт), а когда есть время (обычно я сразу такое делаю) посмотреть, например, не вышла ли новая тестовая версия старого пакета, который не даёт обновиться зависимости, тогда разрешаем обновиться ему до тестовой - и готово. Этот рецепт работает в 90% случаев :) Иногда отказываюсь от тестовой версии пытающегося обновиться пакета, если вижу, что меня и стабильная уже удовлетворяет.

>Кстати, я весь пост не осилил прочитать... =)

+1 :) Прочёл только первых несколько строк и потом - вопросы гентушникам ;)

>а я же люблю лицезреть консоль с выхлопом емерже во время пересборки

Какой ужас :D У меня обычно обновление идёт в screen'е и ionice -c3. Да ещё и с --jobs=N, в несколько потоков, так что выхлопа нет, а только отчёты о процессе работы :)

Вот сегодняшнее обновление на airbase.ru/balancer.ru/etc:
http://img232.imageshack.us/img232/4199/10090.png
(не обновлял до этого 6 дней, обновление прошло за 7 минут, Q9440)

Не, мне так не нравится =)

>Таким образом, если система синхронизована с последними обновлениями в репозиториях, то пакетов «которые уже собраны» не так уж и много

live-пакетов (прямо с VCS'ов) у нормальных юзеров не так уж и много :) А версионные обновляются не так уж и часто.

Кстати, дома с сентября не обновлялся, с этим переездом, блин (((

У гентушников всё просто. При установке пакета в список world записывается только пакет. Зависимости не записываются. При обновлении обновляются только пакеты из world(и если требуется пакет из зависимости по старше то и он).

>Кстати, дома с сентября не обновлялся, с этим переездом, блин (((

У меня как-то серверок был, который год не обновлялся :) Потом обновил как-то и больше его судьбу не знаю. Может быть, до сих пор работает, может поменяли уже :)

# emerge -puND world

These are the packages that would be merged, in order:

Calculating dependencies... done!


так лучше, правда ?

Мб.

Ну так суть в том, что либо одно, либо другое, совместить невозможно.

>Есть ли практика Continuous Integration

Непонятен вопрос.

Каждый раз когда разработчик обновляет исходник, и есть шанс что результат стабилен (предполагаем что разрабочик вменяемый, и не постит в нерабочий код в публичные ветки), то автоматически собирается версия для заказчика-пользователя-тестера которую тут же можно опробовать.

Подробнее есть в Википедии: http://ru.wikipedia.org/wiki/Непрерывная_интеграция

У нас в линуксах этим мало кто из разрабочиков занимается (у Google Chrome вот есть канареечная версия =), соответственно проблему нужно как-то решать конечным пользователям.
Начиная с определения вменяемости репозитория того или иного разработчика (кое у кого таки в репозитории хаос, и собирать это не следует), и заканчивая проблемами производительности о которых собсна этот пост.

>Каждый раз когда разработчик обновляет исходник, и есть шанс что результат стабилен

Я таким не страдаю :)

Вот на этой машине у меня установлен только один live-пакет: =sci-visualization/gnuplot-4.5.9999

Вопрос любителям постоянно пересобирать-обновлять. Как в вашем дистрибутиве обстоит дело с изменёнными конфигами? Отслеживается ли как-то на уровне самих пакетов, чтобы грядущее обновление 100% подхватило существующие конфиги? Или везде просто типа поменялся формат конфига, твоё старое сохранили как .old, разбирайся как хочешь?

я что-то не поняла, на каждый коммит в svn'e пересобирать ?
зачем ?

> Как в вашем дистрибутиве обстоит дело с изменёнными конфигами?

плохо. )

имхо, в конфиге нужно первой строчкой иметь параметр «версия конфига», и сделать так чтобы твоя программа могла сконверить конфиг более старой версии до конфига более новой версии либо вывести сообщение об ошибке

> я что-то не поняла, на каждый коммит в svn'e пересобирать ?

зачем ?

не каждый коммит, а серию коммитов, которая приводит к созданию новой фичи или улучшению существующей.

Ну как: работаешь над фичей, вечером проверил что всё вроде бы работает, прогнал автотесты, посмотрел что тесты прошли, смерджил с транком и пошел домой (или на диванчик ;) спать.
А в это время пользователи по-быстрому обновились с транка и могут пробовать новые вкусности. Одновременно если будут какие-то проблемы, то с утра тебе придут репорты и можно будет пофиксить всё что не работает. Красота!

Осиль уже ccache

Один - два раза в неделю emerge -avuDN world. Впервые сижу полностью на нестабильной ветви ~amd64, но даже при этом кактусы попадаются очень редко, обычно проблема бывает в исходниках, а потому спасает маскировка. Главное не забывать обновлять конфиги (предпочитаю dispatch-conf, ибо всё-таки интересно что там прилетело). Кстати, сомнительное какое-то выражение «пересборка мира». emerge -e @whatever - вот это пересборка (если например тебя осенило, что CFLAGS и иже с ними выбраны неверно, жизнь прожита зря и т.д. ;-) Но такое бывает только по началу).

//и надо уже попробовать paludis, чтоли.

> в конфиге нужно первой строчкой иметь параметр «версия конфига», и сделать так чтобы твоя программа могла сконверить конфиг более старой версии до конфига более новой версии либо вывести сообщение об ошибке

Зачем параметры, если есть «программа --version»?

Просто в том же CentOS я так понимаю обновления проверяются, чтобы от них ничего не отвалилось при обновлении по крону «вслепую». А в генте/арче с этим как?

Лорчую второй пункт, недавно была какая-то свистопляска с Qt 4.7x. В таких случаях иногда помогает самый топорный метод, я например удалил из системы все пакеты, которые были помечены как blocked, прошелся emerge --depclean и поставил сразу последнюю версию с обновлениями. «ЯДНТ»? :}

честно говоря не знаю зачем это может понадобиться _пользователям_ ,
есть конечно энтузиасты, есть проекты находящиеся в перманентном безрелизном состоянии (mplayer например),
в любом случае собирающие с транка должны иметь вескую причину для этого и в любом случае это будет весьма ограниченный список пакетов.

> в том же CentOS я так понимаю обновления проверяются, чтобы от них ничего не отвалилось при обновлении по крону «вслепую»

как без поддержки разработчика можно сказать, что конфиг от программы версии X подходит к программе версии Y?
типа, посмотрел что на новом конфиге программа не вылетела с сегфолтом и отписался «ура, работает!»? )))

Зачем параметры, если есть «программа --version»?

не понял :(

звучит как «выбрать дистрибутив который можно ускорить пересборкой чтобы затормозить его постоянной пересборкой»

>я например удалил из системы все пакеты, которые были помечены как blocked

Тоже вариант. Но суровый :)

>Как в вашем дистрибутиве обстоит дело с изменёнными конфигами?

Gentoo, если обнаруживает, что старый конфиг менялся пользователем, сохраняет новый конфиг под новым именем. И потом, с помощью etc-update позволяет интерактивно и удобно смержить их.

> типа, посмотрел что на новом конфиге программа не вылетела с сегфолтом и отписался «ура, работает!»? )))

Хотя бы так. У некоторых программ ещё есть фича типа проверить корректность текущего конфига. Если ругается, повод покопаться в программе или как минимум пока не выкладывать обновление.

не понял :(

У тебя есть изменённый конфиг и есть соответствующая ему программа. Логично, что достаточно запросить версию самой программы запустив её с ключом --version или подобным, чтобы понять «от какой версии» конфиг.

> честно говоря не знаю зачем это может понадобиться _пользователям_

простым пользователям пишмашек с OpenOffice - абсолютно согласен, нафиг не нужно.

А ползователям, считающим себя частью процесса разработки Линукса как системы в целом, исправно проверяющим новые вкусности из тех чем они сами пользуются, и поэтому сидящим на всяких fedora/rawhide и arch/aur/testing.

Есть еще категория людей, которые хотят иметь самые последние вкусности. На венде они покупают или крякают новую версию Неры, на Айфоне качают новую 30-центовую хернюшку с Аппстора, а на линуксах так вообще полный рай - можно в любой момент пойти куда угодно и собрать любую понравившуюся шляпу ))) Хочешь патч для иксов, позволяющих использовать две мышки и два курсора? Да пожалуйста! Я отношусь как раз к таким. Уверен таких людей оооочень немало.

собирающие с транка должны иметь вескую причину для этого

у меня часть пакетов с других дистрибутивов, есть пакеты собирающиеся с убунтовыми патчами, или наоборот - убунтовые пакеты с патчами от других дистрибов, итп. Они вызывают много головной боли. Достаточно веская причина?

Собсно, пост возник в голове еще месяц назад в результате обновления убунтового скина для гнума, который потребовал ручной пересборки кучи системных пакетов с творческим ручным переосмысливанием списка зависимостей и взаимоотношений нововведений в каком-нибудь GObject.

> Gentoo, если обнаруживает, что старый конфиг менялся пользователем, сохраняет новый конфиг под новым именем. И потом, с помощью etc-update позволяет интерактивно и удобно смержить их.

Понятно. Дроч. :(

> Логично, что достаточно запросить версию самой программы запустив её с ключом --version или подобным, чтобы понять «от какой версии» конфиг.

да узнать-то можно. Каким образом это поможет в миграции конфига на новую версию программы?

>считающим себя частью процесса разработки Линукса как системы в целом, исправно проверяющим новые вкусности из тех чем они сами пользуются, и поэтому сидящим на всяких fedora/rawhide и arch/aur/testing.

для этого не обязательно держать всю систему в -9999 ,
вполне достаточно свежих upstream версий, а -9999 только для того за чем следишь особо.

категория людей, которые хотят иметь самые последние вкусности

последние апстрим версии, снапшоты к крайнем случае (уровня beta1 итд)
но определенно не trunk, тем более для больших проектов

> да узнать-то можно. Каким образом это поможет в миграции конфига на новую версию программы?

Это избавит от необходимости указывать версию программы в конфиге.

>Понятно. Дроч. :(

В чём же? Самый удобный и быстрый метод, что я видел :) Где-то четверть конфигов смерживается вообще автоматически, 90% оставшегося - буквально в несколько нажатий. И лишь изредка, на конфигах, типа php.ini с десятками правок - соответственно, десятки нажатий кнопок :) При чём кнопки обычно двух видов: «l» - взять кусок из старого (слева) конфига, «r» - из правого :)

Вот в недельном обновлении выше обновилось два модифицированных мной конфига. Один смержился автоматом (я даже не запомнил его... сейчас глянул, это был /etc/logrotate.d/elog-save-summary), второй,/etc/fuse.conf - в 4 нажатия («3», «l», «1», «y»):

http://img257.imageshack.us/img257/3397/gentooetcupdate.png

Не думаю, что 4 нажатия в 6 дней - это дрочерство ;)

> а -9999 только для того за чем следишь особо.

а прикинь, если каждый человек который «за чем-то следит особо» соберет бинарный пакет этой штуки.
И тогда хоть ты и не «следишь особо», а все равно легко и просто сможешь иметь последнюю рабочую версию софтинки, ничего не компиляя самому, не смотря вылопы емерже, итп.
Об этом собсна и пост.

Я уже понял что пока на практике не покажешь крутость этой идеи, никто ен поверит -)

а зачем ? нужно еще попасть к закрытию merge window, причем чем больше проект, тем меньше шансов делая снапшот попасть именно в тот момент когда merge window закрыта, а снапшот из открытого merge window может быть заведомым глюкаловом, причем даже багрепорты по нему не интересны, поскольку глюки и проблемы могут уйти с последующими коммитами.


тем более не пойму если человек не следит за чем-то особо, зачем тогда транк ? был релиз - собери , поставь последнюю версию, пиши в багзиллу.

А зачем вам настолько часто обновлять софт? Раз в неделю недостаточно?

Я понимаю раз в полгода запаривает ждать, для этого и существует rolling release. Но раз в час - это уже быстрее, чем разработчики его разрабатывают ;)

>А ползователям, считающим себя частью процесса разработки Линукса как системы в целом, исправно проверяющим новые вкусности из тех чем они сами пользуются, и поэтому сидящим на всяких fedora/rawhide и arch/aur/testing

1. Не надо путать rawhide и прочие кукеры с арчем. Это две огромные разницы.
2. Все эти кукеры не рекомендуются в качестве основного десктопа.

Есть еще категория людей, которые хотят иметь самые последние вкусности. На венде они покупают или крякают новую версию Неры, на Айфоне качают новую 30-центовую хернюшку с Аппстора, а на линуксах так вообще полный рай - можно в любой момент пойти куда угодно и собрать любую понравившуюся шляпу

s/людей/красноглазых идиотов/

> Не думаю, что 4 нажатия в 6 дней - это дрочерство ;)

Не очень понял, что было сделано между «3» и «1».