Category Archives: pkgng

[FreeBSD] pkg quarterlyとlatestレポジトリの共存

Pocket

ここでも触れたが、10.2-RELEASEから、pkgレポジトリのデフォルト参照先がlatestからquarterlyになった。
具体的には/etc/pkg/FreeBSD.confの内容が変わった。

だからして、引き続きlatestを参照したい場合には、/etc/pkg/FreeBSD.confを書き換えればいいや、と思っていたものの、どうもこのファイルは「なるべく触るな」ということのようである。

つまり、もしもの時にlatestを参照する場合には、quarterly(すなわちデフォルト)の他に、latest向けのレポジトリ設定ファイルを作る必要がある。

それぞれを、いちいちenable/disableするのも面倒なので、latest、quarterlyの双方を参照するよう、Multi-repositoryの設定をした。

本記事ではMulti-repositoryの設定方法について示す。
と同時に、普段はquarterlyを使い、特定のときだけlatestを使うための方法を示す。

まずデフォルトの/etc/pkg/FreeBSD.confについて

/etc/pkg/FreeBSD.confは触るな

/etc/pkg/FreeBSD.confの中身を見てみると、以下のような記載がある。

すなわち、この設定を無効化したい場合には、/etc/pkg/FreeBSD.confは触らずに、/usr/local/etc/pkg/repos/FreeBSD.confを作ったうえで、無効化の宣言をしろ、ということである。

/etc/pkg/FreeBSD.confはデフォルト設定として扱いたい雰囲気丸出しであるが、そうならrc.confのデフォルト設定が/etc/defaultsの下にあるように、/etc/pkg/defaults/FreeBSD.conf的なものを作ってくれても良いのではないかと思った。

しかしそもそも、レポジトリの設定ファイルはどのように読み込まれるのであろうか。

レポジトリ設定ファイルの読み込まれる順番

/usr/local/etc/pkg.confで指定する。
上記ファイルの中に、REPOS_DIRがある。
pkgは、ここに記載された順番通りにレポジトリ設定ファイルを読み込む。
特に変更していないのであれば、内容は下記の通り。

仮に複数のディレクトリに、同じレポジトリに対する設定ファイルがあったならば、後から読み込まれたもので上書きされる。
同じディレクトリに複数のファイルがあったならば、ファイルはアルファベット順に読み込まれる。

以下、マニュアルからの引用

Repositories are processed in the order they are found on the REPOS_DIR search path, with individual repository configuration files in the same directory processed in alphabetical order. Settings from files later in the search path will override those from earlier ones.

だから、/etc/pkg/FreeBSD.confのコメントに書いてある通り、/usr/local/etc/pkg/repos/FreeBSD.confでFreeBSDレポジトリを無効にする宣言をすると、設定が上書きされ、めでたくFreeBSDレポジトリは無効になる。

ところで、同じディレクトリ内の読み込み順序はアルファベット順、というのがキモで、実はレポジトリの名前と設定ファイルの名前は別々でも構わない。
だから、読み込ませたい順番に応じて、ファイル名の頭に数字を入れてもよい。

latestレポジトリ向けの設定はどこに?またどうやって?

さて。
仕組みはわかった。
どうも/etc/pkg/は触ってほしくないようだから、/usr/local/etc/pkg/reposにlatest向けの設定ファイルを置けばよいのだろう。
しかしちょっと待て。
latestとquarterlyを両立させるにはどのようにしたら良いのであろうか。

レポジトリの優先度について

複数のレポジトリを参照する場合、どちらをどの程度優先するか。
レポジトリ設定ファイルにpriorityという設定項目があるので、それを使えば優先度の設定ができる、ようだが。

以下はマニュアル。

レポジトリ設定ファイルにPRIORITYで優先度を指定すればよい。
数値が高ければ高いほど、優先度が高い。

ふむふむ。
では、動作は?

優先度設定されたときの動作

「複数のレポジトリが与えられた場合、pkgは、-rで参照先レポジトリを明示されない限り、PRIORITYの順番で検索を行う。」

ほほう。なるほど。
続けて読む。

「異なるバージョンのpackageが見つかった場合、最も高いバージョンが選ばれる。」

アレ!? 話が思わぬ方向に向かってきたよ!
優先度の高いレポジトリからインストールしてくれるんじゃないの!?

「低いバージョンが優先度の高いレポジトリにあったとしてもこの動作は変わらない。」

Oh…。

「さらにさらに、仮にバージョンを指定してインストールを実行しても、
動作は変わらない。
高いバージョンが見つかったら問答無用で新しい方をインストールする。」

ぐぬぬ。

基本、quarterlyを使い、特定のときだけlatestを使うためには

上記の動作を踏まえ、基本、quarterlyを使い、特定のときだけlatestを使うためには、以下の方法がある。

A. 都度、レポジトリ設定ファイルを使い分ける。
B. マルチレポジトリにしつつ、インストール時に考慮をする。

ここでA.を選ぶと芸がないので、B.の方法を示す。
B.の方法と言っても、以下の通りでOK。

最初にquarterlyレポジトリからインストールする。
-rオプションで参照先レポジトリを明示すること。

pkgは、そのpackageをどこからインストールしたかを覚えている。
後に示す設定を変えない限り、アップグレードの際には同じレポジトリを参照してくれる。
だから、最初のインストールでquarterlyを選んでおけば、次回アップグレードのときにも、原則としてquarterlyが選ばれるというわけ。

これをコンサバティブアップグレード(conservative upgrade)といい、pkg.confでデフォルト有効になっている。

説明を読むと;

「(常に高いバージョンを選ぶ)この動作を変更するには、最初のインストールで
-rオプションによりレポジトリを選ぶ。
その後のアップグレードで同じレポジトリを使うには、pkg.confの
CONSERVATIVE_UPGRADEでtrueを選べばよい。」

以上

[FreeBSD] 10.2-RELEASEから適用されるpkg quarterlyてなんだ。

Pocket

10.2-RELEASEから、pkgのデフォルト参照先レポジトリが”quartely”のものになる。

◎pkg.confの変更

ご覧のとおり、いままでは”latest”。
これは言わばpkgのheadのようなもので、最新のpkgは手に入るものの、うっかりインストールすると地雷を踏むことがが多かった。

quarterlyは上記の問題を解決するために設けられる。
中の人によれば「意図的に更新速度を控えめにすることで、問題の発生を抑える一方、セキュリティ更新は受け取れるようにする」とのこと。
もちろん、望ならば今まで通りlatestを参照することもできる。

“In general, the quarterly package set is less prone to having build failures, since the changes in the branch are (by intent) less intrusive, while still receiving security updates. “

latestからquarterlyに変更してバージョンチェックしてみると、すでにインストール済みのpackageからバージョンの下がるケースも見られた。

詳細は待て10.2-RELEASEのアナウンス。

“(This will be noted in the final 10.2-RELEASE announcement, as well as
the release notes, and will also include instructions on how to switch
to the ‘latest’ branch if that is what is desired.)”

中の人の発言は以下から引用。
https://lists.freebsd.org/pipermail/freebsd-stable/2015-July/082905.html

[FreeBSD][pkgng][メモ] pkgを1.2から1.3に上げたらneed to re-create repo FreeBSD to upgrade schema version

Pocket

pkgを1.2から1.3.xに上げたら以下のようなメッセージが出てupgradeができない。

need to re-create repo とか言いつつ、どうすればいいのか書いてないし。
調べたところ、pkg update -fすればいいとのこと。

incremental update completedとのこと。
この状態でpkg upgradeすると、確かに動いた。
表示も少し親切になっていますな。

しかもconflictsを検知してくれるみたい。

以上。

[FreeBSD] あるマシンのpkgをごっそり他のマシンに持っていくには

Pocket

インターネットに接続されていないなどの理由で、公式のpkgレポジトリからpkgをダウンロードできないマシンのpkgをどのように世話するか。

インターネットに接続できるマシンでpkgをインストールしておき、そのマシンからpkgを取得する。

手順

・ターゲットとなるマシン(以下、ターゲット)と同じ構成でVM(以下、コピーマシン)を作る。
・コピーマシンに必要なpkgをインストールする。
・コピーマシン上のどこかでインストール済みpkgを作る。
・同じ場所にrepoカタログを作成する。
・ターゲットと同じLANに繋ぎかえる。
・pkgのあるディレクトリをwebサーバで公開し、pkgをインストールする。

以下、詳細手順

ターゲットと同じ構成でVMを作る

RELEASEバージョンを合わせておけばよいでしょう。
割愛。

コピーマシンに必要なpkgをインストールする

タイトルの通り。
なにもわざわざインストールしなくても、という意見もあるだろうが、動作確認も必要だし。
割愛。

pkgを作る

適当な場所にディレクトリを掘り、以下のコマンドを叩く。

-aは、インストール済みのすべてのpkgを指定、という意味。all。
-fは、圧縮フォーマットの指定。右から左へ移すだけだからtgzでよい。tbzだと時間がかかる。
-o ./は、作成したpkgを置く場所。
-nは、作成済みのpkgを作らない、という意味。付けると処理のスピードアップが望めるが、逆に更新のあったpkgを作り忘れる、という危険性もあるかも。
以下の例では-nを使っていない。

repoカタログを作成する

pkg repoにディレクトリを指定すればよい。

そうすると以下の二つのファイルができる。

つまり今回の例でいえば、/usr/home/vanilla/pkgrepo/に作成したpkgと二つのファイルが格納されているわけ。

以上でコピーマシンでの作業は完了。

ターゲットでの準備

ターゲットにpkg一式をコピーし、webサーバを立ち上げる。
そのまえに、ターゲットでレポジトリの設定ファイルを修正しておくこと。
具体的には、①公式のpkgレポジトリを無効にし、②自前のpkgレポジトリの設定を加えることである。

①公式pkgレポジトリの無効化

/etc/pkg/pkg/FreeBSD.confでenabledをnoにする。

②自前レポジトリの設定
/usr/local/etc/pkg/repos/localpkg.confとして以下のようなファイルを作る。
urlは、後ほど設定するwebサーバと合わせる事。

pkg -vvとしてみる。
repo FreeBSDのenabledがno, repo localpkgのenabledがyesになっていることを確認。

 

webサーバでpkgを公開、インストールする。

rsyncでもなんでも使って、ターゲットにpkg一式をコピーする。
/home/vanilla/10.0/pkgにコピーしたとして、webサーバでこのディレクトリを公開すればよい。
ここでは手早くpythonで公開する。
以下のようにするとカレントディレクトリをルートとするwebサーバが立ちあがる。ポートは8000である。

同じくターゲットでpkg udpate。
pkg repoで作成したdigests.txz, packagesite.txzを参照できていることを確認したら、pkg upgradeすればよい。

以上です。

カスタムpkgをpoudriereで作ろう

Pocket

poudriereとは

中の人曰く:

primarily designed to test package production on FreeBSD. However, most people will find it useful to bulk build ports for FreeBSD.
「package生成のテストを主眼にデザインされたツールである。しかしながら、ほとんどの人はportsをまとめてコンパイルする点を有用と考えるだろう。」

とのこと。

ちなみにpoudriereとはフランス語であり、英語にするとgunpowder magazine、つまり弾薬庫のことだそうな。

物騒であるな。
あと、poudriereって綴りが覚えづらくて困る。

カスタムpackageのためのツール?

一方で、poudriereはカスタムpackageを欲する人にも勧められてたりする。
というのも。
現時点では、pkgでインストールするpackageのオプションは決め打ちされていて自由に選ぶことができない。
有名なところで例を挙げると、PHPのpackageにapacheモジュールが付属しない。
したがって、apacheモジュールが欲しければ自分でコンパイルするしかない。

コンパイルとくればportsである。
poudriereもコンパイルを行うが、こちらはpackageを作ることができる。
packageを作ってしまえば、pkgコマンドで手軽に管理できる。
おお。
これは便利なのか?

しかしながら準備段階でコンパイルが発生しているわけで、わざわざpkgコマンドなんて経由しないで、portsからコンパイルしてさっさと入れてしまったほうが効率的だろう。

それでもpoudriereが有用なケース①: 複数ホストが対象のとき

ずいぶんネガティブなことを書いたけれども、もしもカスタムpackageを複数ホストで使うのならば、poudriereの利点が活きてくる。
poudriereの優れているところは、公式のpackageレポジトリの構成とまったく同じものを作る点だ。
そのディレクトリをwebサーバで公開するだけで、自前のレポジトリができてしまう。
クライアントでは、pkgコマンドの見に行く場所を自前レポジトリに向けるだけでよい。

やってみると分かるけど、同じLANにあるレポジトリはめっぽう速くて気分がよい。速いのはあたりまえだけど。
こうしたことから、カスタムpackageを複数ホストにばら撒くならpoudriereはとても有用である。

それでもpoudriereが有用なケース②: オフラインマシン向け

もう一つ加えるとすれば、オフラインのマシンにpackageを展開する場合だろう。

pkgコマンドにはcreateというサブコマンドがあり、インストール済みのpakcageからpackageを再生成できる。
これを利用して、ネットに繋がるマシン(たいていはセキュリティポリシー上許可されたマシン(多くはWindows)の「上で」動く仮想マシン)でpackageをインストールしてpkg create、ネットに繋げないマシンにまるまる移すことができる。

また別の考え方をすると、テスト環境でpackageをインストールして検証し、問題のないことを確認したら、packageを本番環境に移す、ということもできるだろう。

ただこの方法には問題があって、現時点のpkgコマンドにはインストール済みのpackageをリプレイスする仕組みがないのである。

例えばターゲットとなるマシンのbashを更新したいとする。
通常であればpkg upgradeを使うところだが、このコマンドは手許にあるpackageを読んでくれないのである。
(もしできるのなら教えてください本当に)
どうしようもないので、いったんbashをアンインストールしてから再インストールするという、なんだかすごく頭の悪いことをする羽目になる。

bashなら悠長なこと言ってられるかもしれないが、これがサーバソフトウェアなら大変である。
またこれが1つ2つではなく、数百個になったらどうするのか。

ここで告白するが、私はとても面倒くさくなって、packageを根こそぎ削除して新規にまるまるインストールしようとした。
そしたら、pkgコマンドも削除されててリアルでorzとなった。
みんなは気をつけるように。

話を戻すと、こういうウッカリさんには、poudriereは便利、かもしれない。

注意点

仮想マシンでpoudriereを動かす人は以下の点に注意すべき。
端的に言って、firefox等のブラウザ、libreofficeなどの巨大packageを作る際には、膨大なメモリ、swapが必要である。メモリ、swapそれぞれ1GBでは失敗した。
メモリを用意できない場合には、出来合いのpackageを持ってくるしかないだろう。
なお、ブラウザに限って言えば、operaなら悠々とコンパイルできたことをお伝えしておく。

ながながと前置きをしたが、以下にpoudriereでカスタムpackageを作る方法を示す。

前提

便宜上、「インターネットに繋がっていない」ことを「オフライン」と表現する。
「オフラインマシン」であれば、「インターネットには繋がっていないマシン」とする。
ただしオフラインマシンであっても、LANには接続されている前提。

ネット接続可能で、poudriereのインストールされているマシンをオンラインマシンとする。

オンラインマシンでpackageを作り、「レポジトリをオフラインマシンにコピーしてから」、オフラインマシンにインストールするという手順にする。
つまりこれは複数のオフラインマシンを前提にしているというわけ。

事前準備

オンラインマシンにpoudriereの環境があること。
作り方は本記事の前編であるこちらをどうぞ。
オフラインマシンには、pkgコマンド、webサーバ(nginx, lighttpd, apacheのいずれか。Pythonでもよい。 Python? ええPythonです)、あとはまあ転送用に、rsyncがあると便利。なくてもよい。

オフラインマシンへのpkgインストールはこちらを。
オフラインマシンへのpackageインストールは、poudriereに関するこちらを。

全体の流れ

poudriereでカスタムpackageを作るときの流れは以下のようなものである。

1.おもむろにテキストファイルを開く
2.カスタマイズしたいpackageの一覧をズラズラと並べる。
3.このとき、origin付きで並べること。php5ならlang/php5というように。
4.poudirereのサブコマンドoptionsを使って一括でoption設定をする。
5.あとは同じファイルでbulkコンパイルすればよい。

では。

カスタマイズしたいpackage一覧の作成

一例として、以下のようなファイルを作る。
pkg.custom.txt

originの探し方はpkg search -o phpなどとすればよい。

optionの設定

以下のようにする。

optionsサブコマンドにテキストファイルを与えると、書かれているpackageのoptionを根こそぎ聞いてくれる。

実態は、おそらく当該portsに移ってmake config-recursiveをしている。
それはともかく、素のままoptionsを実行すると、再帰的にmake configされるので大変である。
大量の依存を抱えているといつまで経ってもoption選択が終わらない。ウンザリする。
そもそもカスタマイズしたいpackageだけを書いているのにこんなことをされては迷惑である。
そこで-nオプションを与えて、option設定を一階層に限るというわけ。

packageの作成

あとは同じテキストファイルを、bulkコマンドに与えて上げればよい。
待つだけ。

リポジトリの展開

オンラインマシン(”オンラインマシン”の定義は「前提」章を参照のこと)からオフラインマシンに移す。
オンラインマシンでいきなりリポジトリを公開するケースはこちらを。

さて以下の場所にリポジトリができたとする。

それをオフラインマシンに転送。

rsyncを使った。
ないならtarでもなんでも固めて持っていけ。
ここでは192.168.200.100がオフラインマシン。
オフラインマシンにいる普通のユーザのディレクトリに置いているが、気にしない。

その後、オフラインマシンに移って該当箇所をwebで公開。

pythonが入っていれば以下のコマンドですぐに公開できる(Python 2の例)。

 

オフラインマシンでの設定

以下のような設定を書けばOK。

 

リポジトリの設定を変えたら必ずpkg -vvで確認。

 

あとはpkg updateしていつもの流れ。

 

以上。

poudriereでhomebrew(自前) pkgリポジトリを

Pocket

poudriereを使ったので経緯を記す。
poudriereは自前のpkgngレポジトリを作るツール。
自前のレポジトリを作るのは、自前のpackageを置きたいときや、オフラインマシンにpackageを提供したいとき、である。

poudriereの構築は、以下二つのサイトに沿えばできる。
ただ、簡潔にまとめられているので、本記事では補足も併せてまとめる。
http://blog.etoilebsd.net/post/Home_made_pkgng_repo
http://w.vmeta.jp/tdiary/?date=20130205

仕組み

poudriereがどのようにしてpackageを作るかというと。
OS/アーキテクチャごとにjailを作り、そこでportsからpackagesを作る。
つまりホストのOS|アーキテクチャと違っていても大丈夫だが、ホストは最新にしておいた方がよい。

packagesはあるディレクトリにまとめられる。
ディレクトリはそのままwebで公開できる形式になっている。
他のマシンから、pkgngでつなげば、自家製packagesを取得できる。

作成するpackagesは自分で選ぶことができる。
また、オプションも選ぶことができる。
オプションはまた別途。

必要なもの

zpoolを最低7GB用意しておくこと。

インストール

ports-mgmt/poudriereからportsでもpkgでもよいのでインストール。

設定ファイル

まず設定ファイルを作る。
/usr/local/etc/poudriere.conf.sampleをもとに。

/usr/local/etc/poudriere.conf

 

poudriere作業用zfsの準備

zpoolからzfsを切り出し、/poudriereにマウント。
poudriere.confを参照すると、最低でも7GBとある。

zfsの操作はよろしければこちらをどうぞ。
http://april.fool.jp/blogs/?p=1827

結果として以下のような環境。
20.0Gのzpoolをvaultとして作成している。

ここからpoudriereとして切り出し。

それを/poudriereにマウント。

再起動しても大丈夫なようにfstabに書き込み

以降、本格的な作業に。

デフォルトのportstreeを作る。: poudriere ports

jailごとにportsディレクトリを持っていてはディスクがいくらあっても足らない。
そこでportsディレクトリは全jailsで共有する。
そのportsディレクトリ、portstreeを作る。

poudriere ports -cで作成。
場所は/poudriere/ports/defaultに作られる。

ちなみに、二回目からは-uで更新。
指定がなければportsnapが使われる。
svnとかが使いたければ-m svnなどと指定する。

作成例

二回目以降の例
すでにportsがある状態で-cを指定すると怒られる。

 

各システム向けのJailを作る: poudriere jail

いよいよ個別のjail。
pkgを提供したいシステムに合わせてjailを作る。

jailを作るにはpoudriere jailを使う。
poudriere jailでオプション一覧が表示される。

-jでjailname指定、-vでFreeBSDバージョン、-aでアーキテクチャ(i386かamd64)を指定。
-cで作成、-dで削除、-lで一覧、-sで開始、-kで停止、-uで更新。

後で見返した時に分からなくなるので、jail名にはシステム関連の情報を入れておくとよい。
たとえば9.2-RELEASE i386向けなら92i386というように。

実行例

一覧の例

削除例

このときのmountの出力
えらいことに。

 

jailの作成が失敗するとき

失敗しなかったらこの章は読み飛ばしてOK.
最初のCreatingで失敗するときは、以前に作った何かが邪魔しているはず。

zfs listすると同じ名前の残骸がある。

削除。オプションなしではうまくいかないので-rで再トライ。

きれいになった。

 

作成したいpackagesのリストを作る

作成したいpackagesを指定する。
テキストファイルにpackagesを並べればよい。

ただしOriginで記載すること。
Originっていうのは…たとえばrsyncならnet/rsyncと書く。
Originが分からなければ、pkg searchするときに-oを付ければよい。

psearch(ports-mgmt/psearch)でもできる。

試しにrsyncだけ書く。

 

packagesの作成: poudriere bulk

いよいよ作成。
作成にはpoudriere bulkを使う。
poudriere bulkでオプションを一覧できる。

-fで作成するパッケージリストを指定。さっき作ったやつ。

特定のjailでのみ実施したい場合は-jでjailname指定。
-cで作成したpackagesをすべて吹き飛ばす。
-C -f <file>に書かれたpackagesのみ消す。

では実行。
初回なのでpkgも作ってくれているようですな。

 

自家製packagesの公開

さて。
作成したpackagesはどこにあるかというと、今回の場合は以下である。

このディレクトリをwebサーバで公開する。
※もちろん、webサーバで公開しているディレクトリに中身を移しても可。

この場所は、poudriere.confのPOUDRIERE_DATAで決まる。
${POUDRIERE_DATA}/packages/<jailname>-default/となる。
もしこの場所が気に食わなかったら、POUDRIERE_DATAを変える。

lsで中身を見てみると、オフィシャルpkgsiteのものと全くそっくりな内容になっている。

ではこれをwebサーバで公開する。
ここではnginxを例にとる。
nginx.confは下記のように。

デフォルトからほとんど変えていない。
変えたのは、#Here!と記載した箇所。
rootを/usr/local/poudriere/data/packagesに向ける。
autoindexをonにする。
nginxは、デフォルトではautoindex offなので、明示的に指定しないとForbiddenを食らってしまう。

nginxを起動して;

接続確認。良さそうですな。

webサーバを他の用途にも使っている場合には、以下のようにlocation /packages/を/usr/local/poudriere/dataに向ければよい。
※冗長なのでserverディレクティブの中しか引用しない。

 

クライアント側の設定

やっとたどり着いた。
クライアント側では/etc/pkg/の下か、/usr/local/etc/pkg/repos/の下に以下のような設定ファイルを作る。
ここで192.168.200.111はサーバのアドレス。

/etc/pkg/homebrew.conf

こうしておき、pkg -vvとすると見えるはず。

pkg updateするとさっき作ったpackagesも見える。

いろんな工夫については別途。

pkgのデータが壊れたでござる。よろしい。消しておしまい。

Pocket

pkgngで色々と遊んでたりすると、ごくごく稀に以下のような表示が出ることがある。

 

要するにpkgのdatabaseが壊れたということである。

これを復旧するにはどうしたらよいか。
実はすごく簡単だし、大した問題ではない。
ここで壊れているのは、repository catalogueつまりpkgサーバに何が格納されているか、というデータベースなので、消してもう一回ダウンロードすればよい。

 

として、それからpkg updateすればよいだけ。
ただし削除するときは注意。
local.sqliteは、そのホストにどのpkgがインストールされているか、というデータベースである。
これを消してしまうと、当然ながらそのホストにはpkgが一つもインストールされていない、ということになって、たいへん面倒なことになるから注意。
告白すると私は一度やりました。ええ。

[メモ] pkgngで更新のあるpackagesを一覧にするには

Pocket

pkg updateとやったあと、更新のあったpackagesを一覧するには。

スマート: “pkg version -vRL=”とすればよい。
かっこよくない: いきなりpkg upgradeして表示させる。

実行例

…なんか面倒くさいことになってるけど、この通り。

portsのINDEXを使う場合

/usr/portsがあり、OSバージョンに合ったINDEXがあれば、version -vIL=も使える。
INDEXとは、/usr/ports/INDEX-10などの、portsの目次。
portsを使わない場合は不要だけど、poudriereで自家製packagesを使うときには重宝するかも。

 

オプション補足

-Iと-Rの違いは下記の通り。

-vと-Lの意味は以下の通り。

 

pkgngが死んで詰んだときには

Pocket

 

pkgコマンドが何らかの要因で壊れてしまい、pkgコマンド自体の再インストールすらできず詰んでしまったときの対処方法を示す。
お急ぎの方は「蘇生方法」からお読みください。

背景: pkgはベースシステム?package?

pkgコマンドは、ベースシステムに組み込まれていながら、pkgシステムで管理されている。
言い換えると、ベースシステムに含まれているのに追加ソフトウェアとしてのpackagesでもある、というちょっと変わった存在である。

これは、pkgコマンド自体を、OSのバージョンに固定されることなく、更新できるための仕組み。
pkgコマンドが純然たるベースシステムであった場合、pkgコマンドを更新するたびにOSリリースが発生してしまうからである。

だから、皆さんご存知の通り、初めてpkgコマンドを実行すると最新のpkgをダウンロード&インストールするのだが、それは上記のような理由である。

なお、ここでの「ベースシステム」とは、FreeBSD projectがリリースする一式(カーネル+ユーザランド)を指す。packagesはユーザが任意に追加するソフトウェア。

問題: pkgはpackageなのでpkgが壊れると詰む。

よろしい。背景は、わかる。
しかし、問題もあって、すなわち;
pkgコマンドもpkgngで管理しているので、pkgコマンドが壊れてしまった場合、pkgの再インストールができず詰む
ということである。

たとえば、pkgコマンドが依存しているshared objectが無くなったとか、壊れた場合である。
FreeBSDではこういう場合に備えて、/rescueにスタティックリンクされたコマンドが並べられているが、pkgはここにない(9.2-RELEASEで確認)。

どうしたらよいか。

蘇生方法: pkgコマンドをダウンロードして、それでpkgコマンドをインストールせよ。

結論。pkgのpackageにはスタティックリンクされたpkgが含まれているのでそれを使う。
以下、手順。

pkgコマンドのダウンロード

まず、pkg.freebsd.orgからpkgコマンドのpackageをダウンロードする。
OSバージョン、アーキテクチャに合ったpackageを選ぶこと。

9.2 i386なら、以下
http://pkg.freebsd.org/freebsd:9:x86:32/latest/Latest/pkg.txz

10.0 amd64なら、以下
http://pkg.freebsd.org/freebsd:10:x86:64/latest/Latest/pkg.txz

※URLは変わる可能性があるので、都度、確認すること。
pkg.freebsd.orgから辿っていけばよい。

実行例

pkg-staticの取り出し。

以下のようにしてpkg-staticを取り出す。
このpkg-staticがスタティックリンクされたpkg

pkgのインストール

このpkg-staticを使って、ダウンロード済みのpkg packageをインストールする。
ローカルにダウンロード済みのpackageをインストールする場合には引数にaddを与える。
壊れたpkgが邪魔でインストールできないなら、-fを付けて強制的にインストールする。

あとは通常通りpkg updateなど。

pkgの設定確認

pkgの設定を一覧したり、どのリポジトリを見ているかを確認するにはpkg -vvとする。
pkgについて、誰かに質問するときには、この出力も必ず付けること。

pkgの設定ファイルなど。

以下があれば何とかなるはず。

/usr/local/etc/pkg/repos/FreeBSD.conf

以上

[メモ] FreeBSD10.0-RC5にしたら全pkg/portsを再インストールしろ

Pocket

メモ。

FreeBSD 10.0-RC5にしたら、おなじ10.0からのアップグレードであっても、pkg/portsの再インストールが必要。
というのもABIの変更があったから。

必ずしもすべてのpkg/ports、というわけではないが、全部やっておいた方が安心。

ソースは以下。
http://lists.freebsd.org/pipermail/freebsd-stable/2014-January/076817.html

pkgの再インストールは以下のコマンドで。