shoorick

Обновил на рабочей машине FreeBSD с версии 7.2 до 8.0 — при этом перл с версии 5.10 вернулся на 5.8.

upd/18:16: Обновил перл обратно на 5.10, стал обновлять зависимое от него ПО, а обновить коллекцию портов — забыл. В итоге получил массу сообщений вроде такого:

Downgrading 'p5-TimeDate-1.20,1' to 'p5-TimeDate-1.16,1' (devel/p5-TimeDate)

Балда!

Обновил trac 0.11.5 → 0.11.6. Нечаянно. Специально, помня предыдущий апдейт, я его бы обновлять не стал. Как всегда, всё сломалось. Пока пытался починить, выяснил, что в системе одновременно было установлено три питона: python24-2.4.5_4, python25-2.5.4_2, python26-2.6.4. Апач пытался найти трак среди приложений питона 2.5, при том, что основным был питон 2.6.

Починить удалось путём отсечения Змею двух голов из трёх замены двух старых версий питона на одну новую (portuprgade -o lang/python26 lang/python25; env FORCE_PKG_REGISTER=1 portuprgade -o lang/python26 lang/python25) и последующей пересборкой апачного mod_python.

Попутно, раз уж взялся налаживать trac, всё-таки настроил автоматическое приписывание комментариев к тикетам — трак может, встретив в комментарии к коммиту ссылку на тикет (например, вида re #123), добавить в этот тикет комментарий, а в некоторых случаях (fix #456)— и закрыть его.

Раньше подобный фокус не удавался: на машине используется много хранилищ трака и лишь одно, общее — у subversion; в результате hooks/post-commit всегда получал один и тот же адрес SVN-хранилища, вне зависимости от того, в какой из частей дерева был сделан коммит. Научить скрипт распознавать, в какой части дерева сделаны изменения и, соответственно, к какому траковому проекту обращаться — задача тривиальная; странно, что я не сделал это два года назад. В общем, надо добавить в hooks/post-commit одну строку, и ещё одну — поменять:

PROJECT=`/path/to/svnlook dirs-changed $REPOS -r $REV | head -n 1 | cut -f1 -d/`
TRAC_ENV="/path/to/trac/db/$PROJECT"

Захотелось странного — обновить каталист с 5.7 до 5.8: в новом обещали всякий much easer да much faster. Ну и обновил. А до кучи — и остальные перловые модули, что были в портах. В результате и зайцев не спас, и перед партизанами неудобно выяснилось (чё, спрашивается, сразу не посмотрел?), что в портах каталист старый — 5.71001 и после обновления всё загнулось: и свежие, ещё не закоммиченные версии разрабатываемого сайта, и более старые.

Причина крылась в том, что некоторые модули поменялись, а некоторые — вообще стали deprecated, например, Catalyst::Model::DBIC и http://search.cpan.org/perldoc?Catalyst::Plugin::Authentication::Store::DBIC. И в DBIx::Class что-то поломалось.

Решилось пляской с бубном перегенерацией модулей, описывающих структуру базы данных, командой

script/app_create.pl model Dbase DBIC::Schema Dbase create=static dbi:mysql:БД[:хост] логин пароль

При этом модули создались не там, где раньше, а на один уровень глубже — в каталоге Result.

Пробовал задавать create=dynamic, чтобы поменьше получалось — не выходит: сервер не запускается. Пришлось пока остановиться на этом методе. Почитал мануалы, попробовал погуглить — без особого успеха. Домой пришёл лишь в 22:45.

P. S. Видя такой бардак, решил до кучи и перл проапгрейдить до 5.8.9 — проапгрейдил, но наткнулся на очередные грабли: в портах почему-то нет Catalyst::Plugin::RequireSSL — пришлось ставить через perl -MCPAN -e shell.

Заапгрейдил на домашней банке FreeBSD с 6.2 до 7.0.
В целом, работает. Правда, NTFS-ные партиции перестали монтироваться. Но, вроде, мне попадался метод решения — нагуглю ещё раз, исправлю.

А там и на рабочей обновлю.