アカウント名:
パスワード:
RedHatにしろDebianにしろ中途半端にしか知らない人間としては、実際のところどちらがどのように優れていてるのか、メリット・デメリットは何か、という議論を期待したいところ。
Vineみたいに、パッケージはrpmだけどユーザーインターフェースとしてaptも使える、とか言われると、もう何がなんだか(笑)
できればFreeBSDのport/packages辺りまで含めてもらえるとモアベター。
とりあえず、sysutils/portupgrade をお勧めしておきます。
バージョン違いで別途入ってしまう、は ports とて一緒です。この辺りの事を楽にしたいのであれば、portupgrade を利用するのが一番です。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
人生の大半の問題はスルー力で解決する -- スルー力研究専門家
ここでも何か．．． (スコア:0, フレームのもと)
別にどっちでもいいじゃん。好みor用途によるんだからさ。
いい加減飽きない？
＃最近Debian->NetBSDに浮気中
Re:ここでも何か．．． (スコア:1, 興味深い)
パッケージ管理機構に関する議論希望 (スコア:1)
RedHatにしろDebianにしろ中途半端にしか知らない人間としては、実際のところどちらがどのように優れていてるのか、メリット・デメリットは何か、という議論を期待したいところ。
Vineみたいに、パッケージはrpmだけどユーザーインターフェースとしてaptも使える、とか言われると、もう何がなんだか(笑)
できればFreeBSDのport/packages辺りまで含めてもらえるとモアベター。
Re:パッケージ管理機構に関する議論希望 (スコア:1)
私の思うports/packagesの良いところは、
・バイナリ配布版のpackagesと、コンパイルする（つまりいじれる）portsが、ともに同じ管理データベースを使っていて混在できる
・portsは雛型をとってくれば、makeでオリジナルのソースをとってきてパッチ当てしてくれます。雛型はcvsupすればいいし、makeするだけでいいし、パッチの追加も簡単だし、インストールすればpackage版も作れます。あと、ソースはとってくるので著作権等でバイナリ配布(できない|しかだめな)物もいけます。
悪いところは、
・バージョンの違うpackages（たとえばapache-1.3.23とapache-1.3.26）が別のものとして管理される。
＃たとえばapache-1.3.23をインストールした後、apache-1.3.26をインストールすると、/usr/local/libexec/apacheは上書きされますが、packagesではそれぞれインストールされた物として管理されます。portsはインストール時に見つけてくれたと思います。
ただ、この点はportupgradeというツールを使えば大概回避できます。（前版の情報を消してくれる）
・packagesの依存関係は管理データベースのみでチェックされるので、ports/packagesによらずインストールした物があっても認識されない。（でも回避ぱ簡単）
＃portsはバイナリの存在を検知してた気もしますが、そこら辺りはMakefile依存でしたっけ。
ん～、書いているうちに殆ど理解していないことが判明致しました（汗
誰か添削してください。あと、必然的にrootになる必要がありますが、ここらへんの考え方についても知りたい。
なんにしても、この手のツールは、
・コンパイルなんて面倒。バイナリをさくっとインストールしたい。
・パッチ当てたい。コンパイルさせろ。
・いいじゃん。オリジナル持って来たんだからインストールさせろ。
・なんだよ、どうせなら全部まとめて面倒見ろよ。面倒なのは嫌いなんだよ。
・いじり倒させろ。でもゴミ残すな。
って言うわがままをどうかわしているかが重要かと（笑）
Re:パッケージ管理機構に関する議論希望 (スコア:1)
とりあえず、sysutils/portupgrade をお勧めしておきます。
バージョン違いで別途入ってしまう、は ports とて一緒です。この辺りの事を楽にしたいのであれば、portupgrade を利用するのが一番です。