[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ruby packages

Subject: Re: ruby packages
From: "Akinori MUSHA" <knu@iDaemons.org>
To: Takahiro Kambe <taca@sky.yamashina.kyoto.jp>
Date: Sun, 25 Feb 2001 02:58:35 +0900
Organization: Associated I. Daemons
Message-ID: <86vgq0vu7o.wl@archon.local.idaemons.org>
In-Reply-To: <200102241522.f1OFMFu73019@eterna.binary.net>
References: <200102200904.f1K94Fg02158@edge.sky.yamashina.kyoto.jp><200102200931.f1K9VQg02216@edge.sky.yamashina.kyoto.jp><861ysta8vz.wl@archon.local.idaemons.org><200102241522.f1OFMFu73019@eterna.binary.net>
Cc: tech-pkg-ja@jp.netbsd.org
Delivered-To: mailing list tech-pkg-ja@jp.netbsd.org
Mailing-List: contact tech-pkg-ja-help@jp.netbsd.org; run by ezmlm-idx
User-Agent: Wanderlust/2.5.4 (Smooth) SEMI/1.14.2 (Daish�ji) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.2 MULEXEmacs/21.1 (patch 14) (Cuyahoga Valley) (i386--freebsd)

At Sun, 25 Feb 2001 00:22:07 +0900,
Takahiro Kambe wrote:
> 今のところはそうですが、lang/ruby-base/Makefile.common としてまとめる
> よりは、分割しておいた方が楽ではないかとも思い始めています。例えば、
> USE_RUBY_RD による依存関係は text/ruby-rdtool/Makefile.common に置くと
> 言った感じです。

　なるほど。それはひとつの考え方ですね。

> > 　私は安直に、 bsd.ruby.mk を元にしている以上は、極端なことを
> > 言えば diff の結果を.if ～ .else ～ .endif でくるむだけでも、
> > なお共通部分の方が多く、同期していくメリットは大きいと思って
> > しまったんですが、そういう思い込みは乱暴なのかもしれません。
> 長短所からも検討の余地は十分にあると思います。

　その後考えたのですが、結局、同期というのは無駄が多いように
思えてきました。YAGNI ですな。OpenPackages が具現化したら、結局
変換する手間が掛かるのは同じなので、そのときに合わせればいいこと
ですよね。

　一方的に提案しておいて取り下げるのは心苦しいですが、お互いに
いいアイデアは交換して参考にする、程度で行きましょうか。 :)


　以下は長い余談です。

> LIB_DEPENDS	廃止
> RUN_DEPENDS	廃止
> 
> BUILD_DEPENDS	パッケージの作成時の依存の記述

> FETCH_DEPENDS	パッケージの配布ファイルの取得時の依存の記述

> DEPENDS		パッケージが作成や実行等で依存するパッケージの記述

　これについては、 NetBSD pkgsrc がその時点ですでに /usr/local と
/usr/pkg を分けていたことを踏まえると、ごく自然な前進だったと私は
捉えています。

　つまり、パッケージシステムがその中で閉じて管理できるようにする
代償として、ユーザが手で導入したライブラリやツールの類の利用・
共存という道を(ほぼ)切り捨てる英断の一環であるということです。

　少し刺激的な表現をすればこれはすなわち、依然として LOCALBASE=
/usr/local をデフォルトとし、あくまで port はユーザの自分の手に
よるインストールの代行、便宜手段、なる考えを守る FreeBSD ports
というシステムからの訣別・昇華である、と言えます。


　私自身は、 Debian や RPM の高度なパッケージ管理手法をある程度
知ってからは、 FreeBSD ports をパッケージシステムとして改良して
いくことよりも、ビルド支援システムとして磨いて行く方があるべき
姿に近いような気がして、そちらに重心を置いています。

　具体的に言うと、閉じたパッケージ管理システムでは実現が難しい、
ビルド時のオプション指定やカスタマイズ、ユーザが自分で導入した
バージョンのライブラリやツールの利用といったことです。

　そういう考えの元、 FreeBSD ports では Ruby の複数バージョンの
共存をサポートし、手動でコンパイル・導入された ruby に合わせて
ライブラリの ports をインストールできるようにしたというわけです。
(そんなに大がかりな仕掛けが必要だったわけではないです、念の為)

　一方、 NetBSD pkgsrc と比べ、パッケージシステムとしての FreeBSD
ports は中途半端でいろいろと不便なので、 ruby でいろいろフレーム
ワークを実装して、アップグレードツールを書いて便利に使っていたり
します。 ;)

　早くもリファクタリングが必要になっているので、フレームワークを
再構築してきれいにしたら FreeBSD port にしようかと思っています。

> そうそう、OpenBSDはportsベースでnamedをインストールしたくらいしか経験
> はありませんが、make installしたら、
> 
> 1. 仮のパスにインストール
> 2. バイナリ・パッケージを作成
> 3. それをpkg_add
> 
> とかしたみたいで、くらくらしました。

　FreeBSD ports でひとつ問題なのは、一般ユーザ権限でパッケージを
作ることが難しい、また個々の port がそうできる保証をしていない、
ということです。

　セキュリティを重視する OpenBSD としては、一般的なソフトの導入
手順である make, su, make install を一歩進めて、仮のインストール
までを一般ユーザ権限でシミュレートできるようにしてやることで、
導入時の安全確認等を行いやすくするという意味があるわけです。

　ちなみに、パッケージを先に作成してからインストールする手順は
Debian package や RPM package も同じですね。

-- 
                     /
                    /__  __            Akinori.org / MUSHA.org
                   / )  )  ) )  /     FreeBSD.org / Ruby-lang.org
Akinori MUSHA aka / (_ /  ( (__(  @ iDaemons.org / and.or.jp

"We're only at home when we're on the run, on the wing, on the fly"

Follow-Ups:
- Re: ruby packages
  - From: sakamoto@splhack.org (Kazuki Sakamoto)

References:
- Re: ruby packages
  - From: Takahiro Kambe <taca@sky.yamashina.kyoto.jp>
- Re: ruby packages
  - From: Takahiro Kambe <taca@sky.yamashina.kyoto.jp>
- Re: ruby packages
  - From: "Akinori MUSHA" <knu@iDaemons.org>

Prev by Date: ご興味のない方には申し訳ありません。
Next by Date: Re: ruby packages
Prev by thread: Re: ruby packages
Next by thread: Re: ruby packages
Index(es):
- Date
- Thread