GNU/LinuxとBSD Unixのパッケージ概観

Last Update:


なぜパッケージに注目するのか

パッケージ(package)はオペレーティングシステム(OS)の重要なインフラのひとつだ。OSと聞くとプロセス管理・メモリ管理・ファイルシステムといったカーネルの機能を連想してしまいがちだ。『4.4BSDの設計と実装』『詳解 Linuxカーネル』『オペレーティングシステム 設計と理論およびMINIXによる実装』といった分厚い書籍を思い浮かべるかもしれない。でもそれよりももっと高いレイヤのアプリケーションだって立派にOSの一部だ。プログラマにとって統合開発環境やテキストエディタ・バージョン管理システム・コンパイラは欠かせない。一般ユーザにとっても統合デスクトップ環境が提供する豪華なグラフィカルは欠かせない。特にWebブラウザはもうそれ無しで生活することなど考えられないような時代になっている。

Debian GNU/LinuxやRed Hat Enterprise Linux(RHEL)のようにOS全体をパッケージで管理しているケースもあれば、NetBSDやFreeBSDのようにベースシステムに無いソフトウェアをパッケージで管理しているケースもある。システム管理という面ではパッケージはとても便利な機能なので、FreeBSDではベースシステムをパッケージ化してパッケージマネージャから管理できるようにするPkgBase[FreeBSD Wiki]が開発されているくらいだ(NetBSDも昔syspkgというPkgBaseと同じコンセプトの実装が進められていたが現在は停滞している[NetBSD Wiki])。

パッケージは、カーネルハッカーはともかく一般ユーザにとっては一種のインフラのようなものと言っても過言ではない。それをどう作りどう配布するのか?を調べると、OSはどのような構成をしているのかおおまかに眺めることができる。そしてこれをものにすれば、自分で好きなGNU/Linuxディストリビューションあるいはデスクトップ向けのBSD Unixを作ることだってできるだろう。

OSに興味はなくても、パッケージには向き合わなければならないときもある。もしなにかコードを書いてFLOSSとして公開するなら、そしてGNU/Linux向けにそれを書いたのであれば、deb(5)rpmをいつでも(できれば両方)作れるようにしておいたほうがいい。企業でGNU/Linux向け商用ソフトウェアを開発するときも、そのソフトウェアをパッケージにまとめる作業は恐らく必要になるはずだ。

古典的にはconfigureしてmakeしてmake installが王道ではあるし、ソースパッケージをビルドしてバイナリパッケージにするときはこれがおこなわれるものの、ユーザにソフトウェアを提供するならパッケージは欠かせないものとなっている。

Unix パッケージのはじまりは?

パッケージは「荷物」や「梱包」の他にソフトウェアの管理・配布形式(形態?)も意味する。しかしこの言葉がいつからソフトウェアに対して使うようになったのか分からない。確かに「ソフトウェアやその設定ファイル・マニュアルなどを含んだ単一のアーカイブ」は言われてみれば荷物っぽいし、実際にこれを作るときはまるで段ボールのような箱にデータを詰め込んでいる感覚があるので「パッケージ」という言葉はまさにぴったりだ。ただ、最初にそれを言い始めたのはいつ・誰なんだろうか。

パッケージはよく「ソフトウェア・ライブラリ・設定ファイル・マニュアルなどをアーカイブにしたもの」というような説明がされる。僕は「パッケージ自身の情報(メタデータ)」をこの説明に付け加えたいといつも考えてしまう。たとえばDebian GNU/Linux上でdpkg(1)apt(8)といったパッケージマネージャを実行してなんらかのパッケージをインストールするとき、インストール対象のパッケージが依存している別のパッケージも自動でインストールされたりあるいはサジェストされたりするのはすべてメタデータのおかげだ。

メタデータはソフトウェアのパッケージにのみ存在するわけではない。僕たちが引っ越しや贈り物の準備をするとき、段ボールにモノを詰め込むだけでなく、配送業者向けに宛先や送り主の名前を書いた伝票を段ボールに貼り付ける。これもメタデータといっていいだろう。

おそらく、テープやCD-ROMの形態でソフトウェアを「梱包」して販売する企業が初めに「パッケージ」をソフトウェアに対しても使い始めたのだと予想している。しかしこのような配布形態にはパッケージマネージャが読み取り可能なメタデータはおそらく含まれていないだろう。パッケージをソフトウェア+メタデータのアーカイブという観点からすると、起源であるにせよこれではまだ機能が不足している。現在僕たちが何気なくapt(8)から操作する、Unix上で扱われるパッケージの形式はいつ成立したのだろう。

GNU/Linuxとパッケージマネージャ

パッケージ主体のGNU/LinuxディストリビューションはDebian GNU/Linuxが先陣を切った。Debian 0.01から0.90までのリリースについては不明だが、1994年1月のDebian 0.91は「このリリースは、パッケージのインストールおよび削除ができる単純なパッケージシステムを備えていました」[Debian, 2017]とされ、1995年3月のDebian 0.93R5では「基本システムのインストール後は、パッケージマネージャ (dpkg) がパッケージのインストールに使われました」[Debian, 2017]とある。

しかしDebian GNU/Linuxがパッケージに関して独占的であったかというと、そうではなかったようだ。GNU/LinuxディストリビューションをCD-ROMの形態で販売したRed Hat社が提供したRed Hat Linuxは、1994年の夏にRed Hat LinuxとそのパッケージマネージャRPPの展示のためにプレビュー版(バージョン0.8)がリリースされ、1994年10月31日にバージョン0.9となるHalloweenがリリースされた[Red Hat, 2014][Stephen, 2006]。Debian GNU/Linux 0.91のリリースと同じ年だ。「Fully "packagized" system for fine-grained installation control, easy upgrades, and simple distribution mechanism for your applications」[Red Hat, 1995]とアピールされたのは1995年のバージョン1.1なので、Halloweenの時点でOS全体がパッケージ管理されていたのかは定かではない。

Linuxカーネルが公開されたのは1991年の8月だった[Linus, 1991]。GNU/LinuxディストリビューションそのものはDebian GNU/Linuxではなく、1993年7月にリリースされたSlackwareが本源だ[Slackware, 2005, Chapter 1]。しかもSlackwareはRed Hat Linux(のおそらくプレビュー版以前)より先にパッケージマネージャpkgtool(8)を実装していたという。しかしパッケージの依存関係はチェックせず、doinst.shというポストインストールスクリプトを実行する簡素なものだったようだ。

There's a myth that's been going around ever since RedHat debuted RedHat Package Manager, that Slackware has no package management tool. This simply couldn't be further from the truth. Slackware has always included a package manager, even before RedHat existed. While not as full-featured or as ubiquitous as rpm (or for that matter deb), pkgtool and its associated programs are every bit as good at installing packages as rpm. The truth about pkgtool is not that it doesn't exist, but that it doesn't do any dependency checking.[Slackware, 2005, Chapter 18]

GNU/Linux以前

ではSlackwareがパッケージとパッケージマネージャを取り入れた最初のUnixだったのだろうか?それを確定させるにはSlackware以前のUnixについて調査する必要がある。これは難しい。386BSD(1992年2月)や4.3BSD、System Vなどの他に、4.2BSDやSystem Vの後継製品も調査しなければならないからだ。

AT&TのSystem ⅢまたはSystem Vの後継製品は、AT&T、Altos、Apollo、Compaq、Convergent、HP、Honeywel、IBM、ITT、Intel、Interactive、Masscomp、Microport、Microsoft、Motorola、NCR、NUXI、Opus、SCO、Silicon Graph ics、Sperry、Sun、Tandy、UniSoft、Wollongongから販売されていた。さらに、Amdahl、Apollo、Apple、CrayDEC、Data General、HP、IBM、Intel、Motorola、Unisys、およびほかのホストから、独自のUnixが発売されていた。それらの一部は、4.2BSDに基づいていた。[Salus, 2000]

これはそう簡単に調べられるものではないが、共立出版株式会社の『UNIX System V コマンド・ノート』がたまたま手に入ったので調べてみると、少なくともこの本の中にはパッケージの操作に関するコマンドは載っていなかった[System V, 1986]。

FreeBSDのports(7)は1993年12月にリリースされたFreeBSD 1.0から登場し、NetBSDとOpenBSDにも広まっていった[ports(7), 2014][FreeBSD]。386BSDから分岐したBSD Unixの中でFreeBSDが初めてこのようなパッケージ管理システムを実装した(NetBSDで主に使われるpkgsrc(7)ports(7)から派生した[pkgsrc, 2018])ので、ports(7)の前身が分かれば自ずと答えが分かるのだろうか?

代表的なUnixとそのパッケージ

Debian GNU/Linux

Debian GNU/Linuxはdpkg(1)を通じてdeb(5)形式のパッケージを操作する。dpkg(1)のエンドユーザ向けインタフェースにapt-get(8)apt(8)などがある。パッケージをインストールするなら、最近は後者がよく使われているようだ。

apt(8)でvimのパッケージをインストールするには以下のように実行すればいい。

# apt install vim

dpkg(1)からパッケージをインストールする方法もあるが、一般ユーザは恐らく使う機会がない。

deb(5)パッケージの構造

Debian GNU/Linux stretchのvimパッケージ vim_8.0.0197-4+deb9u1_amd64.debを例にdeb(5)形式のパッケージの構造を眺める。これをar(1)で展開すると

vim_8.0.0197-4+deb9u1_amd64.deb/
├── control.tar.gz
├── data.tar.xz
└── debian-binary

この3つのファイルが得られる。

これらのファイルについてはdeb(5)のマニュアルが詳しい。

The first member is named debian-binary and contains a series of lines, separated by newlines. Currently only one line is present, the format version number, 2.0 at the time this manual page was written. Programs which read new-format archives should be prepared for the minor number to be increased and new lines to be present, and should ignore these if this is the case.

If the major number has changed, an incompatible change has been made and the program should stop. If it has not, then the program should be able to safely continue, unless it encounters an unexpected member in the archive (except at the end), as described below.

The second required member is named control.tar. It is a tar archive containing the package control information, either not compressed (supported since dpkg 1.17.6), or compressed with gzip (with .gz extension) or xz (with .xz extension, supported since 1.17.6), as a series of plain files, of which the file control is mandatory and contains the core control information. The control tarball may optionally contain an entry for ‘.’, the current directory.

The third, last required member is named data.tar. It contains the filesystem as a tar archive, either not compressed (supported since dpkg 1.10.24), or compressed with gzip (with .gz extension), xz (with .xz extension, supported since dpkg 1.15.6), bzip2 (with .bz2 extension, supported since dpkg 1.10.24) or lzma (with .lzma extension, supported since dpkg 1.13.25). [Debian]

要するにcontrol.tar.gzdebian-binaryはパッケージのメタデータで、data.tar.xzがソフトウェアやライブラリ・マニュアルなどに相当するわけだ。

Red Hat Enterprise Linux

RHELはrpm(8)を通じてRPM(Red Hat package Manager)パッケージを操作する。エンドユーザ向けインタフェースにYellowdog Updater Modified(yum(8))やDandified YUM(dnf(8))がある。

企業や大学のネットワークで動くGNU/Linuxは、RHELかその派生であるCentOSが採用されている場合が多い。サーバ機器製品のOSとしてRHELがあらかじめインストールされていることもある。そのため商用製品として監視ツールやWebサーバ・メールサーバといったシステムソフトウェアを配布するのであればdeb(5)よりむしろRPM形式が使われるだろう。Eric Raymondは開発者と共同作業するためのFLOSSのディストリビューション方法について次のように述べている。

RPM(Red Hat Packageマネージャ)は、Linuxのもとでインストール可能なバイナリパッケージのための事実上の標準となったフォーマットである。RPMはもっともポピュラーなLinuxディストリビューションの重要な機能であり、他のほぼすべてのLinuxディストリビューションでサポートされている(DebianとSlackwareを除く。そして、DebianはRPMからインストールできる)。そこで、プロジェクトサイトは、ソースtarボールの他に、インストール可能なRPMも提供するとよい。[Raymond,2007]

FreeBSD Ports Collection

FreeBSDはPorts Collectionは「Makefile, 修正パッチ、 説明文などの一連のファイルのこと」[FreeBSD]で、一般的には短縮してports(7)と呼ばれる。パッケージのビルドやインストールなどの一連の命令はすべてBSD Makeを使う。たとえばGNU Emacsをインストールするときはroot権限で

# cd /usr/ports/editors/emacs
# make install
……と実行する。コンパイル時のconfigureのオプションはビルド途中に選択できる。

最近のFreeBSDでは、ライセンスの都合上バイナリの配布を禁じられている場合やオプションを自分で細かく制御したい場合を除き、pkg(8)でバイナリパッケージをインストールするのが楽だ。先ほどのEmacsの例はpkg(8)を使うと

# pkg install emacs

……となる。このpkg(8)は「FreeBSD 10.X系移行で動作するように設計されて」[FreeBSD]おり、FreeBSD 11.0では基本システムにインストールされている。

ここで、ports(7)あるいはpkgsrc(7)におけるパッケージの表記方法について述べておきたい。ここではEmacsパッケージをインストールする例を示したが、このパッケージは/usr/portsディレクトリから見た相対パス名でeditors/emacsと書かれるのが一般的だ。このような書き方をすると、どのディレクトリに当該パッケージが存在するのか一目瞭然だからだ。

NetBSD pkgsrc

NetBSDのpkgsrc(7)はFreeBSDのPorts Collectionから派生したパッケージ管理システムだ。特徴としてNetBSD以外のUnixでも使える高い移植性がある。NetBSD以外のOSで初めてpkgsrc(7)が動いたのはSolaris 2.6だという。

In 1999, I was working at an investment bank in London, and needed a packaging system to manage third-party software on a fairly large network of Solaris 2.6 machines - pkgsrc fitted the bill, and so the first non-NetBSD platform was Solaris, followed closely by Linux.[Weinem]

ports(7)と同じくpkgsrc(7)上の操作はBSD Makeを使う。NetBSD以外のUnixで使うときは、はじめにbootstrap/ディレクトリ内のbootstrapスクリプトを実行すればよい。その後、bootstrapでインストールされたbmake(1)を使ってパッケージを操作する。たとえばvimをインストールするのであれば

# cd /usr/pkgsrc/editors/vim
# make install

……とする。

まとめ

はじめになぜパッケージに注目するのかを説明した。パッケージはOSのインフラで、便利で手放せないものだ。

そしてGNU/LinuxとBSD Unixのパッケージについて簡単に述べた。GNU/LinuxはDebian GNU/Linux系とRHEL系以外にも多くの種類があるのでとてもじゃないが追いきれない。BSD Unixもまた然りだ。でもたかだか4種類のOSのパッケージ管理を比べただけでもかなりの差異があることに気づく。なぜそう設計したのか?祖先はなんなのか?と考えると、調べることはたくさんあるのだなと思ってしまう。

そしてそもそも、Unixパッケージのはじまりは?という問いに答えられていない。Slackwareの簡素なパッケージか、もしくはPorts Collectionの親がいたのか。課題は残るし調べ足りないことばかりだ。

参考文献

  1. FreeBSD Wiki, PkgBase, https://wiki.freebsd.org/PkgBase, last edited 2018-09-10 21:04:58 by BradDavis
  2. NetBSD Wiki, syspkgs, https://wiki.netbsd.org/projects/project/syspkgs/, Last edited early Thursday morning, February 27th, 2014
  3. Debian Documentation Team, Debian 小史, https://www.debian.org/doc/manuals/project-history, 2.22 (last revised 17th June 2017)
  4. Red Hat Enterprise Linux Team, 20 Years of “Halloween:” Celebrating the First Release of Red Hat Linux, https://www.redhat.com/en/blog/20-years-%E2%80%9Challoween%E2%80%9D-celebrating-first-release-red-hat-linux, 2014
  5. Stephen John Smoogen, The Truth Behind Red Hat/Fedora Names, https://www.smoogespace.com/documents/behind_the_names.html, Update 2006/06/19
  6. COMMERCIAL: Red Hat Commercial Linux 1.1, Pacific Hi-Tech CD set., https://groups.google.com/forum/#!topic/comp.os.linux.announce/Optn4pqWFsw, 1995/08/01
  7. Linus Benedict Torvalds, What would you like to see most in minix?, comp.os.minix, https://groups.google.com/forum/#!topic/comp.os.minix/dlNtH7RRrGA, 1991/08/26
  8. Alan Hicks, Chris Lumens, David Cantrell, Logan Johnson, Slackware Linux Essentials, http://www.slackbook.org/html/introduction-slackware.html, 2005
  9. Peter H. Salus, QUIPU LLC訳, UNIXの1/4世紀, 株式会社アスキー, ISBN4-7561-3659-1, 2000
  10. ソフトウェアインフォメーションセンタ 編, UNIX System V コマンド・ノート, 共立出版株式会社, ISBN4-320-02284-X, 1986
  11. David O'Brien (originated by him), ports(7), FreeBSD Miscellaneous Information Manual, 2014
  12. The FreeBSD Project, FreeBSD プロジェクトについて, https://www.freebsd.org/doc/ja_JP.eucJP/books/handbook/history.html
  13. Alistair Crooks, Hubert Feyrer, The pkgsrc Developers, The pkgsrc guide, http://www.netbsd.org/docs/pkgsrc/introduction.html, $NetBSD: index.html,v 1.144 2018/09/18 03:20:54 maya Exp $
  14. Debian Project, deb(5), dpkg suite
  15. Eric S. Raymond, 長尾高弘 訳, The Art of UNIX Programming, ASCII, 2007
  16. The FreeBSD Project, Ports Collection の利用, https://www.freebsd.org/doc/ja_JP.eucJP/books/handbook/ports-using.html
  17. Mark Weinem, 10 years of pkgsrc - pkgsrc and the concepts of package management 1997-2007 (part 1), http://www.netbsd.org/gallery/10years.html
  18. The FreeBSD Project, pkg によるバイナリ package の管理, https://www.freebsd.org/doc/ja_JP.eucJP/books/handbook/pkgng-intro.html