上川純
一
|
今 回 の 事 前 課 題 は 以 下 で す 。
この課題に対して提出いただいた内容は以下です。
パッケージ自体を作ることにはあまりはまったことはないですが、 最近、 locale は UTF-8 が主流になってき ていますが、 仮想ターミナルで動く EUC-JP なプログラムを UTF-8 対応しようとした時、 文字コードのバ イト数が 2 バイト固定から 2-4 バイトに可変となっているため、 コードを大幅にいじらないといけなくなって いる場合があります。 これからのユーザは UTF-8 でインストールするでしょうし、 UTF-8 対応を無視もでき なくて、 困っています。 あと、 どうでも良いことですが、 dh-make がポリシー 3.7.3 に対応したテンプレを吐 くようになるのはいつになるのかな?
某 巨 大 掲 示 板 の 専 用 ブ ラ ウ ザ kita2 をオフィシャルに上げようと思っています。 アップストリームの作者には 必要なファイルを入れてもらうよう交渉したところ。 次期リリース待ち。
VCS は使っていません。 是非、 私にお薦めして下さい。
今まで本格的にパッケージを作ったことがないので、 はまったことはないです。 強いて言うなら、 どこから手をつけていいか分 かっていないところとか、 Makefile が分からないってことでしょうか。 既存のパッケージを参考にしようとしたのですが、 何 をやっているのか分からず、 とても難解に見えます。 Makefile の記法を覚えるところから始めようと思ってい ます。
私の作ってみたいパッケージは、 探せば誰かが作っていたりするので、 これはぜひ私が!というものはないです・・・。 更新が頻 繁にされて、 パッケージかが追いついていないものを自前で作成する時がほとんどです。 あとは、 自作のソフトくらいでしょ うか。
パッケージを作った事は無いので、 作ってみたいパッケージと言う事で考えてみました。 インターネット公開サーバを個人で管 理してたりすると、 あるとちょっと安心なのが krfilter です。 これは iptables でフィルタするための IP アドレ スのリスト (設定スクリプト付き) です。 韓国 (kr) だけでなく中国 (cn) や台湾 (tw) もあり、 個人的にはこ れに .br とか .th も要りそうな気がしてます。 本格的なサーバには RBL(DNSBL) の方が良いかも知れま せん。
思いつくのは cvs ですが、
開発元にお伺いを立てて変更を依頼したり、 物によっては日本語ライセンスのみで英訳が必要だったりしま す。 ライセンス解釈の問題があったりすることもありますし、 non-free と扱われて reject を食らうことも。
自分のマシンだと experimental が混じっているので、 依存関係の問題が出たことが数回。
すでに作りかけのパッケージがいくつも…。
技術的な話ではないのですが、 ライセンスのとこで悩みます。 GPL を採用していると謳っているソフトウェアで も、 下記のような感じで書き換えていないのものがあると、 本当に GPL 採用しているのかと困ってしまい ます。
> one line to give the program’s name and an idea of what it does.
> Copyright (C) yyyy name of author |
パッケージをつくっても、 自分で使う為だけにしかやらないのはそういうところが、 面倒だからなんだと思います。 きっと。
はまったわけではないですが、 debian/control などの debian/以下をどのように書くべきか、 いつも悩みます。
HTML::DOMbo という CPAN モジュールが便利なのですが、 CPAN モジュールということ、 名前がちょっと怪しいというこ とで微妙です。
勉強会/懇親会には欠席の予定ですが、 課題だけ。
もう語りつくされたことだと思いますが、 CVS 以上の VCS なら、 「いつどこでバグが入りこんだか突き止めやすい」 というこ とでしょうか。 たとえテスト駆動開発をしていたとしても、 回帰テストをすり抜けるバグというのもありうるわけで、 その点で も、 いつまでも重要なメリットだと思います。
LD_PRELOADを使うようなパッケージを作ろうとした時に、 共有ライブラリにバージョンが付いているからダメというような lintian の警告ではまりました。 これに限らず、 lintian には良く解らない理由で何度も何度も怒られました。 ポリシーを理解し ていないからなので自業自得のような気がします。
今頃になって CVS で管理していたいろいろなモノを git に移行しています。 git を使ったおかげでディレクトリの移動が簡単 に出来るようになりました。 遠慮せずにローカルレポジトリにガシガシコミットすることも出来ます。 でも時々、 更新されない CVS のキーワード$Id:$などを見るたび物悲しくなります。
あるライブラリをパッケージ化したときに、 ちょっとパッチを当てる必要があって修正を行ないました。 そのライブラリの Makefile ではコンパイル単位のソースファイルがいくつかのディレクトリに分散して置けるようになっていて、 Makefile はそ のディレクトリを順番にソースファイルを探しにいくように (GNU make の vpath) なっていたのです。 修正前のファイルをた またま vpath の手前にあるディレクトリに置きっぱなしにしていたためにコンパイルしなおしても修正が反映されない原因が わからなくてハマりました。
OCaml 言語のネイティブコンパイラに動的ライブラリをビルドする機能がマージされたのですが、 その機能が入ったコンパイ ラおよび、 ライブラリ一式を Debian 化して使えるようにしたいです。 リリース版のバージョンに入るにはもうしばらくかかり そうなので。
研究室で大きなシステムを組むことになったとき、 VCS は欠かせません。 実際に作成するシステムのプログラム群 の管理はもちろんのこと、 ドキュメントなどの関係者全員で共有したいデータの管理にも有効です。 特に研 究室などでは、 メンバーが集まる時間がなかなか合わなかったり、 人によってはリモートアクセスで開発等 を行ったりするため、 データが更新されるタイミングがわかりづらいこともあります。 そのような場合に、 VCS を用いることで最近変更された箇所などを把握しやすいことは、 システム開発を進める上で大きな利点 です。
はまったのとは少し違いますが、 パッケージを作成するのに複数のスタイルがあることに混乱しました。 debhelper、 CDBS、 dpatch、 dbs、 quilt、 yada の使い分け、 関連性がよく分かりません。 それぞれメリット・デメリットがあると思いますが、 複 数のスタイルがあることで、 何を使えば良いのか分かりにくいと感じました。
debian のパッケージに関しては、 今年の3月1日に試みたのが初めてで、 講義の速度についていけず、 未完に終わったと いう恥ずかしい経験しかないもので、 何を書いてよいのやら・・・。
無難に「自作のプログラムをパッケージにしてみたい」 と書こうと思ったが、 最近プログラムを書いていなかった。 (某 OS上ではマクロとかスクリプトとかを山ほど書いては捨てているのですが・・・)
第
39 回東京エリア Debian 勉強会 2008 年 4 月
____________________________________________________________________________________________