日本ソフトウェア科学会第 32 回大会 (2015 年度) 講演論文集

変更履歴を利用したパッケージ管理のためのバージョン管理システム
藤井 亮太

岩崎 英哉

パッケージとは，ソフトウェアを構成する複数のファイルを一つにまとめたものであり，ソフトウェアの管理単位として広く用いられている．パッケージのユーザは，自分の動作環境に合わせるために，インストールしたパッケージに対して変更を加えることがある．しかし，一般的なパッケージ管理システムは，ユーザによる変更を把握していないため，新しいバージョンのパッケージにユーザの変更をマージしたり，ユーザによる変更を別の環境で再現したりすることができないという問題がある．本研究は，バージョン管理システムと既存のパッケージ管理システムを連携させることで，上の問題点を解決する．提案するシステムは，パッケージに対する変更の履歴をパッケージの情報と対応付けて管理し，パッケージ管理システムから利用できるようにする．これにより，ユーザがパッケージに対して加えた変更を，通常のパッケージ管理の枠組の中で扱うことを可能にする．

イルのように，インストール後にユーザが自分の環境1 はじめにや利用目的に合わせた変更を加えて使用することが想ソフトウェアの配布やコンピュータ上での管理を行定されるものがある．このような変更を加えることで，う際に，ソフトウェアをパッケージという単位で扱う

ユーザごとの環境や要求に合わせてパッケージを利ことが広く行われている．例えば，多くの Linux ディ用することが可能になる．その反面，設定ミスによっストリビューションでは，Linux カーネルからアプてパッケージが正常に機能しなくなるなど，ユーザリケーションに至るまで，様々なソフトウェアがパッの変更に起因する問題も生じうる．さらに，パッケーケージの形で提供されている．パッケージは，プログジを更新したり，環境の再構築を行う際には，ユーザラム本体とそのドキュメントなど，ソフトウェアを構による変更が失われないように配慮する必要がある．

成する複数のファイルを一つのファイルにまとめた形

そのため，パッケージに対して加えた変更を把握し，で提供され，パッケージ管理システムと呼ばれる専用適切に管理することは，パッケージを利用する上で重のツールを用いることで，ユーザのシステムにイン要である．

ストールして利用できる．パッケージには，内容物でしかし，一般的なパッケージ管理システムは，インあるファイルに加えて，パッケージの名称やバージョ

ストールされたパッケージに対するユーザによる変更ン，パッケージ間の依存関係などのメタデータが含まを把握しておらず，その管理にも関与しない．そのた

れている．パッケージ管理システムは，このメタデー

め，パッケージに対して加えた変更を何らかの形で記タを利用してパッケージを適切に管理する．

憶ないし記録し，その情報を必要に応じて利用する

パッケージに含まれるファイルの中には，設定ファことは，ユーザの責任において行わなければならな
い．このことは，定期的にパッケージを更新しながら継続的にパッケージを利用する上で，ユーザの負担とRyota Fujii, Hideya Iwasaki, 電気通信大学大学院情報理工学研究科, Department of Communication Engineering and Informatics, The University of ElectroCommunications.

なる．
このような問題に対して，etckeeper [1] や Conary[2] といった，バージョン管理システム (VCS) とパッケージ管理システムを組み合わせることで，ユーザによる変更の履歴を管理できるようにするツールが存在する．しかし，これらのツールには，VCS によって記録した変更履歴をパッケージ管理に利用するための機能が不足していたり，他のパッケージ管理システムと共存できないなど，機能性や利用可能な環境に関する問題がある．
このような問題点を解決するため，本研究では，既図1

パッケージに対する変更存のパッケージ管理システムと連携しながら，ユーザがパッケージに対して加えた変更の履歴を管理し，利の主要な原因であることが知られている [3]．誤った用することを支援する VCS を提案する．既存のツー設定変更による障害への対処の一つとして，問題が発ルと比較した際の本システムの特長は，変更履歴の記生する前の設定内容を復元することが挙げられるが，録と利用の両面においてユーザを支援する点，さらに通常，設定変更は設定ファイルを上書きする形で行わこれを既存のパッケージ管理の枠組を変えることなくれるため，どのような変更を行ったか記憶している実現する点である．

か，コピーを残すなどして古い内容を保存していない

本稿の構成は次の通りである．2 節では，パッケー限り，過去の設定を復元することはできない．

ジに対する変更と，変更履歴の必要性について述べ

また，OS の再インストールなどで一度構築した環る．3 節では，既存のツールの特徴と問題点を述べる．

境を構築し直す場合は，パッケージをインストールし4 節では，本研究で提案するシステムの概要と動作の直した上で，過去にパッケージに対して加えた変更を流れについて述べ，5 節ではシステムの実装について再度行う必要がある．しかし，パッケージに対する変述べる．最後に 6 節で本稿をまとめ，今後の課題を更内容をユーザが把握していない場合，過去に行った述べる．

変更を再現することはできない．
このように，パッケージを正しく動作させるために

2 パッケージに対する変更は，そのパッケージに対する変更内容を常に把握して2. 1 ユーザによる変更おく必要がある．また，その際には，ユーザによる変更の最も典型的な例は，設定ファ• 変更は複数回行われる可能性があり，個々の変イルの書き換えである．図 1 に，プログラム app と更は必ずしも密接に関連しているとは限らない;

その設定ファイル app.conf からなるパッケージ app• 特定の変更に問題がある場合，それだけを取りを例として，パッケージに対する変更の様子を示す．

消すことが可能になっていることが望ましい;パッケージに含まれる設定ファイル (図 1 の (a))

といった理由から，単にパッケージをインストールしはパッケージ提供者が作成した標準的な雛形であり，た直後の未変更のファイルだけを残すのでは，複数回そのままでユーザの要求を満たすとは限らない．その変更のうち，特定の一つだけの内容を確認したり，のため，ユーザはパッケージをインストールした後，取り消すことが難しいため，不十分である．そのた

設定ファイルを自分の環境や要求に合うように編集しめ，個々の変更を行った時点での状態を逐一記録するて利用する (図 1 の (a’))．

ことで，変更の履歴が分かるようにしておくことが必要である．

2. 2 変更履歴の必要性
設定変更により，パッケージをユーザごとの環境や2. 3 パッケージ提供者による変更要求に合わせて様々に利用することが可能となる．しユーザがパッケージをインストールした後に独自のかし，ユーザによる誤った設定変更は，システム障害変更を行う一方で，パッケージの提供者は，古いバージョンのパッケージに対して変更を加えることで新しいバージョンのパッケージを作成する (図 1 の (b))．

3 既存のツール

ソフトウェアのバージョンアップに伴い，設定項目

3. 1 etckeeperの追加，削除やデフォルトの設定値の変更などが頻etckeeper [1] は，Git†1 などの既存の VCS を用い繁に行われる [4]．そのため，図 1 に示した，ユーザた設定ファイルのバージョン管理を支援するツールでの環境 (ユーザによる変更) とパッケージ本体 (パッある．図 2 のように，パッケージのインストールやケージ提供者による変更) の双方で変更が行われるよ更新を行うたびにパッケージ管理システムによって起うな状況は発生しやすい．

動され，VCS を起動して設定ファイルの変更を記録する．

2. 4 変更のマージパッケージ管理システムに連動した動作の実現にユーザがパッケージを更新する際に，新バージョンは，多くのパッケージ管理システムに備わっているのパッケージに含まれるファイルは，旧バージョンのフック機能が用いられている．これは，パッケージ管ファイルを上書きする形でインストールされる．しか理システムの動作中，パッケージのインストール前後し，図 1 の app.conf のようにユーザが変更を加えたなどの特定の時点で，任意のプログラムを起動するこファイルについては，そのまま上書きしてしまうと，とのできる機能である．etckeeper 自体は特定のパッユーザによる変更が失われてしまう．ユーザによる変ケージ管理システムに依存しておらず，パッケージ管更を保持しつつ，パッケージの新バージョンにおける理システムに応じてフックを設定することで，複数の変更を取り込むためには，新旧両バージョンの 2 つパッケージ管理システムに対応することが可能となっのファイル (図 1 の (a’) と (b)) を適切にマージするている．

必要がある．

etckeeper の問題点は，記録した変更履歴の利用にユーザによる変更と，パッケージの側の変更とは，は一切関与しない点である．変更履歴を利用する際，互いに相反する可能性がある．また相反しない場合でユーザは etckeeper が呼び出している VCS を直接使あっても，パッケージ提供者による変更がユーザの意用する必要がある．そのため，図に反している可能性がある．従って，マージ作業にはユーザ自身による判断が不可欠である．
多くのパッケージ管理システムは，更新対象のファイルに対してユーザが変更を加えていた場合，旧バー• 特定のパッケージに関する変更履歴だけを取り出す;• 変更履歴を利用して，2. 4 項で述べたマージ作業を行う;

ジョンのファイル (図 1 の (a’)) を残したまま新バーといったような作業については，全てをユーザが行わ

ジョンのファイル (図 1 の (b)) を別名で保存し，対なければならない．

処をユーザに委ねる．しかし，これら 2 つのファイルを比較しても，どの部分をユーザが変更し，どの部分をパッケージ提供者が変更したのかが分からなければ，どのようにマージすればよいか判断することが難しい．
ユーザによる変更とパッケージ提供者による変更を区別するためには，ユーザの環境とパッケージそれぞれにおける変更内容 (図 1 における (a) と (a’) の差分および (a) と (b) の差分) を把握する必要がある．

図2

etckeeper の動作の流れ†1 https://git-scm.com

3. 2 Conary

しい．

Conary [2] は，VCS が統合されたパッケージ管理

変更履歴の記録と利用をパッケージ管理に統合するシステムである．Conary におけるパッケージは全て上で，Conary のようにパッケージ管理システムを置バージョン管理されており，ユーザは，パッケージにき換えて固定する方法は，利用可能な環境が限定され対して自らが行った変更を記録することが可能であてしまうため，望ましくない．また，パッケージ管理る．また，パッケージを更新する際には，VCS の機システムを置き換えないとしても，通常のパッケージ能を用いてユーザが行った変更とパッケージの側の変管理の手順を変えてしまうと，ユーザの学習コスト更とをマージすることが可能であるなど，変更履歴をが大きくなってしまう．そのため，パッケージ管理へパッケージ管理に利用することが可能である．の統合は，既存のパッケージ管理システムを置き換え

Conary は，VCS とパッケージ管理システムを密ず，また可能な限り既存のパッケージ管理システムのに結合させることで，変更履歴の記録と利用をパッユーザインタフェースを維持した形で実現すべきでケージ管理に統合している．しかし，Conary がパッある．

ケージ管理システムであるということは，他のパッケージ管理システムとは共存できないということで

4. 2 システムの概要もある．OS 標準のパッケージ管理システムが存在す本研究で提案するシステムは，etckeeper や Conaryる場合，これを Conary に置き換えることは，対応しと同様に，ユーザがパッケージに対して加えた変更をているパッケージ形式の違いや，OS 開発元によるサ管理する VCS であり，ユーザが変更履歴を記録したポートの有無といった点が問題となり，現実的ではな

り，記録した変更履歴を取り出すためのユーザインタい．そのため，Conary が利用できる環境は，初めかフェースを提供する．この VCS は，変更対象のファら Conary をパッケージ管理システムとして採用してイルに加えてパッケージのメタデータを記録しておいるシステムに限定される．

り，名前やバージョンなどのパッケージに関する情報を元に，特定のパッケージに関する変更履歴を取り出4 提案システム
4. 1 設計上の要件すことが可能である．
また，提案する VCS は，既存のパッケージ管理シ

本研究では，Conary のように変更履歴の記録と利ステムと連動して動作することで，変更履歴の記録用をパッケージ管理に統合しつつ，etckeeper のようと利用を通常のパッケージ管理に統合する．例えば，に様々な環境で利用することが可能なシステムを提案

ユーザはパッケージに対して変更を加えるにあたっする．提案システムに要求される機能は以下の通りでて，変更前の状態を VCS に記録しておく必要があるある．

が，設定ファイルのようにユーザが変更を加える可能• ユーザがパッケージに対して加えた変更の履歴を記録する．

性が高いものについては，パッケージをインストールした時点で自動的に記録しておくことで，ユーザの行• 変更履歴をユーザが利用することを助ける．

う作業を削減できる．また，2. 4 項で述べたマージ作

後者は，etckeeper に不足していて，Conary には備

業は，パッケージを更新した直後に行うことが望ましわっている機能である．

い．このような，通常のパッケージ管理作業に付随しまた，ユーザの負担を軽減するために，システムを利用する上でユーザが新たに行わなければならない作て行うべき作業は，パッケージ管理システムの動作に連動する形で，可能な限り自動的に実行する．

業は，可能な限り少なくすべきである．特に，通常の以上のように，提案する VCS は，変更履歴の記録

パッケージ管理に付随して行うべき作業については，と利用の両面においてユーザを支援する．また，既存ユーザが明示的に実行するのではなく，パッケージののパッケージ管理システムに連動して動作することに操作に統合された形で自動的に行われることが望ま

より，システムを利用する上でのユーザの負担を低減

する．
本研究で提案するシステムは，パッケージ管理システムに連動して動作するものであり，既存のパッケージ管理システムを置き換えるものではない．また，本システムを導入することで，通常のパッケージ管理操作の手順が変わることもない．ユーザはシステムの導入前と同様に，使い慣れたパッケージ管理システムのユーザインタフェースを利用して，パッケージ管理を行うことが可能である．

4. 3 システムの動作の流れ
図 3 を用いて，2. 4 項で述べたパッケージに対する

図3

システムの動作の流れ

変更のマージを例に，パッケージをインストールしてからマージ作業を行うまでのシステムの動作の流れが対応付けられていることから，ユーザがパッケーを説明する．

ジに対して変更を加えたことがわかる．また，M1 に

4. 3. 1 パッケージを初めてインストールしたとき最初に対応付けられた C1 と，新しいパッケージのメユーザがパッケージ管理システムを用いてパッケー

タデータ M2 に対応付けられた C2 を比較することで，ジをインストールすると，この操作に連動して VCSパッケージの側でも変更が行われたことがわかる．こが起動し，パッケージのメタデータ M1 と，パッケーのように，ユーザの環境とパッケージの双方で変更がジに含まれる設定ファイルの内容 C1 を記録する．こ行われたことが判明した場合，VCS はこれらの変更のとき，M1 と C1 の対応関係を記録することで，ファをマージする必要があると判断し，ユーザに対してイルの内容がパッケージのどのバージョンに基づくもマージを行うよう要求する．のであるか判別できるようにする．

このマージの必要性の判定は自動的に行われるた

4. 3. 2 ユーザがパッケージに変更を加えたとき

め，ユーザは確実にマージの必要性を認識することがユーザは，パッケージをインストールした後，設定できる．また，C1 と C1’ を比較することでユーザ自ファイルを自分の要求に合わせて編集する．その後，身の変更による差分が得られ，C1 と C2 を比較するこVCS が提供するユーザインタフェースを用いて，変とでパッケージの側の差分が得られるので，これらを更後のファイル内容 C1’ を記録する．このとき，C1’ユーザに提示することで，ユーザは自分が行った変更は VCS によって変更元のパッケージのメタデータ M1の内容と，パッケージ提供者が行った変更の内容を明と対応付けられる．

確に区別して認識することができる．これは，ユーザ4. 3. 3 パッケージを更新したときによるマージ作業の助けとなる．

新しいバージョンのパッケージが公開され，ユーザがパッケージ管理システムを用いてパッケージの更新

5 実装を行うと，パッケージをインストールした時と同様に

5. 1 VCS の実装

VCS が起動し，新しいバージョンのパッケージのメVCS の実装は，Git をベースに，独自のユーザイン

タデータ M2 と新しいバージョンのパッケージに含まタフェースを実装する形で行っている．ただし，Gitれる設定ファイルの内容 C2，および M2 と C2 の対応そのものを拡張したり，あるいは外部プログラムとし関係を VCS に記録する．て呼び出すのではなく，Git と同等の機能を提供する

ここで，古いバージョンのパッケージのメタデー
タ M1 に対して C1 と C1’ という複数のファイル内容ライブラリである libgit2†2 を用いることで，Git 形

5. 2 パッケージ管理への統合式のリポジトリを操作している．これにより，本シス

4. 2 項や 4. 3 項で述べたように，本システムの VCS

テムは，Git が導入されていない環境でも利用可能では，パッケージ管理システムに連動して動作する．こある．

れには，etckeeper と同様に，パッケージ管理システ

4. 2 項や 4. 3 項で述べた通り，VCS は変更対象のムのフック機能を利用する．

ファイルだけでなく，パッケージのメタデータを記録する．これには，• パッケージの名称

6 おわりに本稿は，パッケージに対してユーザが加える変更に• パッケージのバージョン起因する問題を解決するために，ユーザによる変更の• パッケージに含まれるファイルの一覧履歴を管理し，パッケージ管理に利用することを支援が含まれる．ここで，ファイル一覧に含まれるそれするシステムを提案した．提案したシステムは，既存ぞれのファイルは，Git リポジトリに記録されているのツールにおける機能性や利用可能な環境の問題を具体的なファイルの内容と対応付けられている．パッ考慮した上で設計されており，変更履歴の記録と利用ケージの情報をもとに変更履歴を取り出す際は，このの両面でユーザを支援することを，既存のパッケージ対応関係を利用する．

管理の枠組を変えることなく実現している．

以上のメタデータは，通常のファイルとして Git リ

現状は，提案したシステムの実装を行っている途

ポジトリ上の特別なディレクトリに格納する．このと上であり，システムの実装を完了し，実用性を検証すき，パッケージのメタデータの形式はパッケージの形ることが目下の課題である．また，現在は特定のパッ式ごとに異なるので，特定のパッケージ形式に依存しケージ管理システム (Apt) を対象として実装を行っない形に変換してからリポジトリに格納する．このているが，これが完了し次第，他のパッケージ管理シ変換処理のようなパッケージ管理システムに依存すステムへの対応作業を行うことを通して，設計上の問る処理は，VCS 本体から呼び出される外部プログラ題が存在しないかどうか確認することも必要である．

ムとして，パッケージ管理システムごとに実装する．
これにより，複数のパッケージ管理システムに対応す

参 考 文 献ることが可能である．

[1] Hess, J.: etckeeper, http://etckeeper.branchable.
com/.
[2] Johnson, M. K., Troan, E. W., and Wilson,
M. S.: Repository-based System Management Using Conary, Proceedings of the Ottawa Linux Symposium, Vol. 2, 2004, pp. 557–571.
[3] Nagaraja, K., Oliveira, F., Bianchini, R., Martin,
R. P., and Nguyen, T. D.: Understanding and Dealing with Operator Mistakes in Internet Services,
Proceedings of the 6th Conference on Symposium
on Opearting Systems Design & Implementation Volume 6, OSDI’04, USENIX Association, 2004, pp.
5–5.
[4] Zhang, S. and Ernst, M. D.: Which Configuration
Option Should I Change?, Proceedings of the 36th
International Conference on Software Engineering,ICSE 2014, ACM, 2014, pp. 152–163.

現在行っている実装では，パッケージ管理システ
ムとして，Debian GNU/Linux 等で用いられている
Apt†3 を対象にしている．Apt は，より下位のパッケージ管理システムである dpkg に対するフロントエンドであり，パッケージファイルを直接操作する処理は，dpkg によって実現されている．そのため，パッケージのメタデータを取得する際は，dpkg を外部プログラムとして呼び出す．

†2 https://libgit2.github.com/†3 https://wiki.debian.org/Apt