bdist_rpm から Py2RPM へ

bdist_rpm is dead, long life to Py2RPM

本稿は上記リンク元の和訳になります
転載ミス、誤訳等については適宜修正します

Python のパッケージングに取り組む中で私が学んだことの1つは、Distutils が利用できるプロジェクトで RPM をビルドする bdist_rpm のような標準ライブラリのスコープツールをメンテナンスすることは限りなく不可能に近いということです。

私が尋ねて回ってみたところ、日々の RPM パッケージングに bdist_rpm を使っていないパッケージャは10人中9人でした。但し、彼らはパッケージングを行うプロジェクトの開発者でもありません。彼らは独自のツールを使います。

いくつか理由があります。

  • bdist_rpm は spec ファイルを作成するときにたくさんの前提条件を必要とする。
  • 生成した spec ファイルのセクションをカスタマイズする方法がない。
  • spec ファイルの作成は、実際に使われる前にパッケージャが時間をかけて編集します。そのため、Pythonメタデータから RPMメタデータを完璧に自動変換することはあまり良い考えではありません。そして、パッケージャはテンプレートをもっているので、最終的には手動で spec ファイルを作成してしまいます。
  • 最新の Fedora ではなく RedHat 5 向けにはどうすれば良いのでしょうか。
  • Python の標準ライブラリのサイクルは、ディストリビューションのサイクルとは一致しません。そのため、我々が標準ライブラリをアップデートしても、それはすぐに古くなって非推奨になるでしょう。

だから、Distutils に bdist_deb コマンドを追加しようと数ヶ月前に提案されたときに、deb ファイルの作成は独立したプロジェクトで行うべきだと私は指摘しました。そして、いまは stdeb がその役割を担っているように見えます。

Windows の場合は少し違っていて、bdist_msi のようなツールはメンテナンスが簡単で、win32 の世界にはあまりパッケージングの "味付け" がなく、たった1つです。Python の標準ライブラリのリリースサイクルは、ここでは確かにうまくいきます。

Distutils から bdist_rpm を排除しよう という原則を支持してください。

そのため、RPM も同様に Python 使いに適切な RPM を提供する独立したプロジェクトになって、Distutils2 (Python 3.3 では packaging モジュールになる) の先頭で bdist_rpm を置き換えます。

現実の問題として、私は Mozilla でのお仕事にこのプロジェクトを少し前に始めて、そのときは pypi2rpm と呼んでいました。PyPI でリリースされたプロジェクトから CentOSRPM パッケージを作成することが主な機能なのでそう呼びました。

試してみよう。

$ pip install pypi2rpm
$ pypi2rpm.py SQLAlchemy
...ログ出力...
/tmp/ok/python26-sqlalchemy-0.6.6-1.noarch.rpm written

このスクリプトPyPI をブラウズしてバージョンをソートするために Distutils2 を使った後で rpmbuild を実行する bdist_rpm のカスタムバージョンを使います。さらに、このスクリプトは、既存プロジェクトにある spec ファイルを使って RPM を作成できます。それは setup.py を迂回します。

しかし、このスクリプトは私が自分の目的のために作成した簡単なスクリプトです。長期的には、Py2RPM に名前を変更して、bdist_rpm を置き換えます。提供したい機能は次の通りです。

サイドノート (これは別のブログの記事) では、setup.cfg は spec ファイルになり、その spec ファイルはバージョン管理されます。{ここにパッケージングシステムの名前を置いて}、これにより RPM の世界にあるツールを使って、似たような機能を提供できます。そして、このファイルは、そのリリースプロダクトの tarball をダウンロードせずに連携できるので、すぐに PyPI で利用できるようになります。

Py2RPM に興味があるなら私まで連絡ください。私は全く RPM の専門家ではないので、一緒にプロジェクトへ参加してくれると嬉しいです。