root
で。その代わり、 Apache を再起動する前に chown -R www:www /usr/local/www/redmine
を実行しておこう。
注意! '24/4/1 付で、Redmine 5.1 が ports 化されています。下記の記述は 4 系列しか ports 化されていなかった時点のものなので、もはやあまり意味を成しません。
が、また新しいバージョンが公開された際に ports の更新が追いつくまでの間は有用かもしれないので、残しておきます。
* Rubygem の管理が ports/pkg と絶望的なまでに相性が悪い。ports を利用し、かつ下記の改修を行なってからインストールする必要がある。
Makefile
は以下の修正をする。rubygem-bundler
以外の依存関係を全部削る。THIN
オプションを設定しない場合)、rubygem-passenger
への依存関係はむしろ足しておいた方がいい。do-install
」ターゲットで行なっている「bundler.d
」ディレクトリの作成は、${STAGEDIR}${WWWDIR}/bundler.d
と ${WWWDIR}/bundler.d
の両方を作成するよう修正する。do-install-〜-on
」ターゲットでのファイルコピーは、${STAGEDIR}${WWWDIR}/bundler.d
と ${WWWDIR}/bundler.d
に格納する。${STAGEDIR}${WWWDIR}/bundler.d
にコピーしないと、build 中に ${STAGEDIR}
内で行なわれる操作で不都合が発生する。${WWWDIR}/bundler.d
にもコピーしておく必要がある。post-install
」ターゲットが最終的なインストール先である ${WWWDIR}
以下にファイルをコピーしてから実行されればこんなことは起きないんだが、なぜか「${STAGEDIR}{$WWWDIR}
へのインストール後」に実行されるので、こんな有様に。pkg-post-install
スクリプト書けばいい気もするんだよ? うん、嘘かもしれないけど? みたいな?post-install
」ターゲットでは、以下の処理を行なうようにする。(cd ${WWWDIR} && bundle config set --local path 'vendor/bundle') (cd ${WWWDIR} && bundle config set --local without 'development test') (cd ${WWWDIR} && ${CP} ${STAGEDIR}${WWWDIR}/Gemfile .) (cd ${WWWDIR} && ${RM} Gemfile.lock && bundle install)
files/patch-Gemfile
は削除する。
* プラグインのインストール時は、プラグインを git clone
したあと、/usr/local/www/redmine/
で以下のコマンドを実行する1)。
bundle update bundle exec rake redmine:plugins:migrate RAILS_ENV=production
bundle exec rake db:migrate RAILS_ENV=production
を実行しろ」という記述も散見されるが、この情報は古い。これを実行すると、必要な処理が行われない場合がある。messenger_settings
)が作られず、プロジェクトの設定画面を出そうとすると Internal Error が発生するようになる2)。
なお、'24/3/6 現在、「Ruby はデフォルトが 3.2 へ移行したが、redmine の port は Ruby 3.2 非対応の 5.0 系のものしか存在しない(ため、BROKEN
とマークされている)」という状態になっている。そこで、Ruby を 3.2 にした上で上記の方法を使って redmine 5.1.1 のインストールができないか試したが、「A formatter class is required (RuntimeError)
」とかいうなぞのエラーが発生して起動しなかった。ぐぬぬ。
前回この記事を更新したのが '24/4/1。そして、実にちょうどその日、ports collection に「www/redmine51
」が生えていた。手元では、その直前に上記と同様に改造して独自に構築してあった。しくしくしく。
なお、インストール済みの環境に対して bundle update
を実行すると、「line 8: Invalid line type
」などなど山のように文句を言われて失敗するときがある(私は commonmarker-2.2.0 でこれを食らった)。
要はネイティブな rubygem を構築する際に GNU make ではなく BSD make が呼ばれてしまうのが原因なのだが、その際に内部で用いられる builder.rb
3)では環境変数「MAKE
」または「make
」で構築時に使用する make ユーティリティを明示できるようになっているので、例えば csh では次のようにしてやると失敗しなくなる。
env MAKE=gmake bundle update
何とはなしに pkg upgrade
を実行したら、passenger が動かなくなって Redmine にアクセスできなくなったりする。そんな時は、まず /var/log/httpd-error.log
を確認する。
uninitialized constant ActiveSupport::LoggerThreadSafeLevel::Logger (NameError)
」と言われたm(_ _)m
)。これに従い、/usr/local/www/redmine/Gemfile.local
がなければ作成し、その中に以下の行を記述する。gem 'concurrent-ruby', '1.3.4'
そして、/usr/local/www/redmime
で bundle update
。
Error loading the 'postgresql' Active Record adapter. Missing a gem it depends on? pg is not part of the bundle. Add it to your Gemfile. (LoadError)
」と言われた(※ PostgreSQL を使用している場合)m(_ _)m
)これに従い、/usr/local/www/redmine/Gemfile.local
がなければ作成し、その中に以下の行を記述する。gem 'pg'
そして、/usr/local/www/redmime
で bundle update
。
Ruby を使用したアプリケーションでは、必要な ruby gem を Gemfile
に記述するようになっている。その際、当然それらは「あればいい」というものばかりではないので必要とするバージョンも指定されるようになっているのだが、「あるバージョンより新しければいい」というものばかりではなく、「新しすぎてはダメ」だったり「ドンピシャで同じでなければダメ」というものもある。これらの要求はアプリケーションごとに異なるので、システムに共通なものとは別に、「そのアプリケーションの動作に必要なもの(バージョン)」を手元にかき集めておく仕組みが用意されている。
一方、ports collection で管理されている rubygem は、基本的に時間経過とともに(通常は最新版を追う形で)バージョンが上がって行ってしまう。これは「そのシステムで共通のセット」を維持する上で特定のアプリケーションにのみ着目するわけにはいかないので当然ではあるのだが、ここで齟齬が発生する。
上記の通り、アプリケーションが使用する rubygem は「新しければいい」というものではない。それなのに ports collection で管理される rubygem は問答無用で更新されて行ってしまうので、上述の Gemfile
も「あるバージョン以降であれば許容する」というように書き換えざるを得ない。その結果、インストールした時点(もっと言えば ports の Makefile
が書かれた時点)では動作していたものが ports/pkg の更新によって動かなくなったり、Makefile
が書かれてからある程度経ってしまうとアプリケーション側が更新されない限りインストールしても動作しなかったりする。増してや、Gemfile
で本来行なわれていた「gem を新しくし過ぎないようにする」制限が取り払われてしまうので、「せっかく(たまたま)うまく動く環境が出来上がっていたのに、うっかり bundle update
を叩くと、その瞬間にアプリがぶっ壊れる」という事態すら発生する。
まあ、結論としては、「ruby gems に関しては、元々 ruby が持っているパッケージ管理の仕組みにお任せしておくのがいいんじゃないかな……」ということ。