ProgenyがDebian強化計画を公表 57
ストーリー by Oliver
楽な世界を目指して 部門より
楽な世界を目指して 部門より
oddmake 曰く、 "Progenyの共同創設者でDebianの創設者のIan Murdock氏がDebian強化計画をメーリングリストで公表しました。内容はRed HatのAnaconda GUI インストーラをDebianに移植する (基本的にはAnacondaをrpmでなくdebを使うように改造)ことと、aptを強化し、debとrpmの両方を扱えるようにし、最終的には、aptユーティリティでdebとrpmの二種類のパッケージが両方混在した環境をも構築可能にする。
個人的には便利そうだけど安定性は大丈夫かなとか心配に思うのですが、それも含めて出来上がりが楽しみです。"
談合 (スコア:1, すばらしい洞察)
いけないすよ。anconda がどれほど、Red Hat のパッケージ達と
談合（というか、示し合わせ）していることか。いや、Debian が
今後そうなっていくならそれでもいいんですが、Debian て今までは、
良くも悪くもインストーラとパッケージ群が談合してませんでしたよね。
それだけに、インストーラが機能的にちょっと寂しいんですけど。
パッケージのメンテナと、インストーラのメンテナ、いろいろと
もめるだろうな～。
# anaconda に泣かされぎみなので AC
期待が大きい！ (スコア:1, 興味深い)
rpm+apt-getが余りに便利で、、。
それを思うとDebianがそうなってくれると、あらゆるプラットホー
ムに対応してくれている状態のままrpmが利用できるようになる訳
で、大賛成です。
そうなってくれるのが待ち遠しいです。
#SRPM持ってきてrebuildしてばかりいるのでAC
Re:期待が大きい！ (スコア:2, すばらしい洞察)
それからaptの周辺ツールの存在も重要です。auto-aptはファイルを探すのによく使いますし、apt-buildやapt-proxy、apt-listchanges、apt-listbugsといったツール群は手放せません。
それで気になるのですが、rpmをサポートするというのはどういうことなんでしょう。
周辺ツールは正しく機能するのでしょうか。apt-lineはどうなるのでしょうか。
alienで変換してインストールするだけということは無いでしょうし、いったいどうやって解決するのか……。
もちろん、企業方面に広まっているrpm形式を扱えるというのは、商用ソフトの対応等の面からも期待が大きいのですが、今はまだ不安と疑念のほうが大きいですね。
Re:期待が大きい！ (スコア:1, 参考になる)
Debianの一番の美点は、aptより、全体で統一されたポリシーがあり、そのポリシーに則った整合性のあるパッケージ群がある（少なくともそれを目指している）事だと思います。
これにrpmをシームレスに組み込むとなれば、現状のalienのように単にパッケージの形式を変えるだけじゃなくて、他の.debパッケージとの整合性を取るツールが必要なのではないでしょうか？
単純にrpmを追加するだけであれば、rpm内にあるバイナリをlddとかして依存するライブラリを抽出して、dependsを設定するというのでもできるでしょうが、rpmに依存するdebパッケージを許す（たとえばrpmで提供されるMTAをDebianのMTAと入替えるとか）のであれば、Provideとかも設定して行かなくてはいけないので、なかなか自動的にというのは難しいかも。
もちろん、現状のままでもとりあえず使わなくてもDebianのMTAを入れておいて、別途rpmのMTAをalienで入れて、設定でDebianのMTAを殺すとかはできますが、これは別の話。単なる逃げ道ですから。
Re:期待が大きい！ (スコア:1)
各々のディストリビューションの特徴がなくなり，Linux らしさが失われていくような気がする．
より良いものを目指す試みの一つなのは理解しているのだが．．．
Re:期待が大きい！ (スコア:1, すばらしい洞察)
大丈夫です。
あなたが特徴のあるLinuxディストリビューションをつくるのを止めることは
誰にもできません。
Re:期待が大きい！ (スコア:0)
Linuxらしさってのは、パッケージシステムうやらディレクトリ構成ポリシーやらコアコンポーネントのバージョンやらが全然違う、「別のOS」と言っても過言ではない代物を“Linux”という名前で一緒くたにすることかい？
Re:期待が大きい！ (スコア:0)
今でも欲しい物の多くは debパケジとして存在しているわけで、
rpmでないと駄目なモノって少ないんですよ、
rpm一発でインストールされるより、逆にmake;make install
した方が環境のポリシーを守りやすいような・・・。
まぁ、今でもdebianの中には rpmがあるわけだし、
de
Re:期待が大きい！ (スコア:1)
... という事を思える程 linux ってメジャーになったんですねぇ。しみじみ。
Re:期待が大きい！ (スコア:1)
Re:期待が大きい！ (スコア:0)
Re:期待が大きい！ (スコア:2, 興味深い)
Re:期待が大きい！ (スコア:1)
そりゃそうなんだけど そうすると『Xでも何でもかんでもひっくるめておまかせInstall』になっちゃうような気がします
ただ KnoppixのVGAに対するXの設定などハードウェアの自動認識は結構優れ物だと思いますので 有効利用出来るといいですね
目的 (スコア:1)
Linux 開発者のパワーをうまく集束させられる結果になればといいと思います。応援しかできないただのユーザで、うまくいきそうなのかとか全然わかりませんが。
# Debian の BTS も Bugzilla にすればメンテナンスが…というのは素人ユーザの考えで、移行コストとかがハンパじゃないんでしょうね。
Re:目的 (スコア:1)
私はあのインターフェイスは控えめに言ってもいいものだと思えません。
今のDebian BTSぐらいがちょうど良く思います。
Re:目的 (スコア:0)
それってDebian側にはほとんどメリットない気が。
先を越されたか (スコア:1)
先を越されてしまったか(w
パッケージ選択画面のコーディングがいやになって、
(RedHatの人はコメントをもう少し多く書きましょう、よめねーYO!)
しばらく詰まっているうちに、急に興味が遠のいて放置していた。
とりあえず、 kernel と debootstrapは動くので痕は
パッケージ選択と apt-setup を持っていけば最小限の環境は出来る?
by rti.
CUIインストーラって (スコア:1)
RedHatみたいにインストールが簡単に終わっちまうと。
スキルレベル低下に繋がるんじゃない？
PCにECC Registeredメモリの利用を推奨します。
Re:CUIインストーラって (スコア:0)
それよりも、ハードウェア（ドライバ、モジュール）の設定のほうが難しい。
Re:CUIインストーラって (スコア:0)
どの程度のハードが自動認識されるか次第だと思う。
Re:CUIインストーラって (スコア:0)
なんてものは当てにしてないんですが。
Debianのインストーラのいいところは、途中でシェルに
抜けて適当に自分でいじってからインストーラにもどれる
ところだと思ってま
Re:CUIインストーラって (スコア:0)
Redhatのヤツは、出来ることが限られてる？
Re:CUIインストーラって (スコア:0)
しかも、すごく出来の悪いUIね。
だからスキルとは全然関係ないと思う。どっちかというと忍耐力だね。
アレに耐えられるかどうかがユーザ認定試験だというなら、
それは理解できます。
Re:CUIインストーラって (スコア:0)
インストール時に必要な雑多な知識はいわばバッドノウハウの一種で、スキルでも何でもありません。
それに真の Debian ユーザ ;-) なら、マシンがよっぽど沢山あるかインストーラ開発者でもなければ、インストールを何度もすることはないはず。
Re:CUIインストーラって (スコア:1)
そうかなぁ？
インストーラで必要な知識ってのは、たとえば HDD のパーティショニングとか、
カーネルに組み込むモジュールの指定とか、ネットワークの設定とかで、
まともに OS を管理する上では必須の項目だけだったと思うぞ。
ってか、Debian インストーラでしか通用しないバッドノウハウって
具体的にどんなのを想定してる？
Debian のインストーラがわかりにくいのは、
「ローカライズされていない（日本語表記でない）」
「自動認識する部分が少ない」「自動設定の選択肢がない」
ところなんじゃないかな。
# mishimaは本田透先生を熱烈に応援しています
Re:CUIインストーラって (スコア:2, 参考になる)
ヘルプか何かに書いてなかったっけ？さほど困らなかった遠い記憶が...
まぁ、数字は覚えていて損はないので意識できるのはよいことかと（笑）
＃メインの165は覚えているけど82ってのは覚えてなかったな。
> それに、Debianを使いたい人全てがDebianをサーバとして長期業務運用したい訳ではないので、管理するなら当然とか言われても困っちゃいます。
サーバじゃなくても短期でも遊びでも管理してください。
さらにお家の場合ならネットワーク管理者であり所有者でもあると思うので特に。
＃これはdebian/linux/unixに限らずと付け加える＜かなり愚痴
ついでに (スコア:0)
Re:ついでに (スコア:1)
にかいてあるとおり、Intel x86 で使えるフレーバーは複数あってbf2.4はLinux kernel2.4をインストールします。
http://debian.fam.cx/?Backport#content_1_2
WoodyではXFree4.1.*ですね。非公式のパッケージはあるようです。公式メンテナーがだした非公式パッケージですね。
#もしかしたら、まったく的を得てない返答かもしれません。
Re:ついでに (スコア:0)
要領は得るが、的は射るもの。
Re:ついでに (スコア:0)
「的を射る」に比して言うなら「当を得る」かな。
Re:ついでに (スコア:0)
なるほど、確かにそうですね。
Re:ついでに (スコア:0)
Re:ついでに (スコア:1)
アクセラレーションなしですがフルカラー1024x768まで行けますよ。
いやならMatroxでも買ったほうがいいです。
PCにECC Registeredメモリの利用を推奨します。
stableを大事にしてほしい (スコア:0)
結局 testing 使えって事なのかなぁ?
--
MMX Pentim 233 の woodyのマシンを2台 sid に上げる作業中なのでAC
Re:stableを大事にしてほしい (スコア:2, 興味深い)
機能追加としてのbackportは「stable」ではないですよね？
大事にしているから「修正は必要最低限」という捉え方もありかと。
ま、testingはうまく働いていないのも問題ではあります。
中途半端な状態というのは否めないですねぇ…
以前にsargeのパッケージでセキュリティホールがあるよ、って
メンテナに言ったら「unstable使え。testingは使えない」で
closeされた、っていう経験があったりします（苦笑
＃私は、ある意味リリースエンジニアリングの壮大な実験の様
に捉えているので、あれこれ考えるのも楽しいのですが…
パッケージ (スコア:0)
パッケージの管理 (スコア:2, 興味深い)
Debian や RedHat 系で tar.gz 波の人って
uninstall とかはどうされてるんでしょう？
まじめに deb-make から自前 package 作成とかしてるんでしょうか？
# もっと簡単に make uninstall とか？？？
uxi
Re:パッケージの管理 (スコア:2, 参考になる)
>uninstall とかはどうされてるんでしょう？
普通のアプリケーションなら、インストール時に checkinstall [asic-linux.com.mx]
を使うのが一番楽ですよ。
『checkinstall を使ってみよう』 [linet.gr.jp]
Re:パッケージの管理 (スコア:3, 参考になる)
必要なくなったとかバージョンアップしたときにはリンクの削除をしてrm -frできるし張り替えもできるし。
-- やさいはけんこうにいちば〜ん！
Re:パッケージの管理 (スコア:1)
うっかり既存のファイルを上書きすることは、まず無いだろ
うし、すごく良さそうですね～。
checkinstall も、簡単で良いんだけど、パッケージを作る
より先に、まず初めに、make install を実行しちゃうので、
ライブラリなんかの場合は、事前に、
# ./configure --prefix=/hoge
としてやらないと、既存のファイルが上書きされる恐れがあ
ります。
Re:パッケージの管理 (スコア:0)
ところで、SlackwareとかFreeBSDのパッケージングシステムって /usr/local下にファイルを配置すると記憶してるんですが(XFree86除く)、 そういうシステムのほうがtar.gz派の人には嬉しくないんじゃないですか?
FreeBSD の場合 (スコア:2, 参考になる)
ports (ソースからインストール) も packages (バイナリからインストール) も、同じ管理情報を利用していますから、削除するのは簡単です。
でも、tar.gz 派の人って、/usr/local の下にアプリケーション名で dir を切ったりして、その下に入れたりするのではないのでしょうか。
もっとも、tar.gz 派の人が packages はともかく、ports を嫌がる理由は分からなかったりしますけど。なぜバイナリパッケージのインストールが嫌なのか。その点を考えてからでないと言えないことではありますが。
ports の場合、別に make install に直行する必要は無くて、make patch した後に適宜変更するなり自分だけ独自に当てたい patch を files 以下に置いて make install することで、パッケージ管理システムに沿って管理させつつ、ソースから任意のカスタマイズを行ったものをインストール可能です。
むしろ、ports のシステムを利用して、独自 ports を書いてしまうのが FreeBSD で任意のソフトを好きに入れつつも、容易に管理する方法だと思います。
Re:パッケージの管理 (スコア:0)
Re:パッケージの管理 (スコア:0)
Re:パッケージの管理 (スコア:0)
インストールは /usr/local にするだけ。
昔からパッケージ管理分と独自インストール分の共存、あと
商用OSならそこがつけてくるコマンドセットも含めての
すみわけが問題だった（
Re:パッケージの管理 (スコア:0)
Re:パッケージの管理 (スコア:0)
Re:パッケージ (スコア:1, すばらしい洞察)
Re:パッケージ (スコア:1)
独裁国家じゃねーんだから (スコア:0)
rpmにしても既存のRHLのrpmのものまでやるんだとすれば
バイナリ互換でないDebianはどーすんだろ。
結局メンテナの負担を増やすだけなんじゃねーの？