Debianパッケージ作成支援ツール「cme」登場、GUIでの操作も可能 40
ストーリー by hylom
使ってみよう 部門より
使ってみよう 部門より
insiderman 曰く、
Debian向けのパッケージ（.debファイル）作成を支援するGUIツール「cme」なるものが登場した模様（Phoronix）。Managing Debian packages with cmeなるドキュメントも公開されている。
Debianパッケージを作成するにはいくつかのやり方があり、柔軟にパッケージ作成を行えるいっぽう、柔軟すぎて学習のハードルは高かった。Debianパッケージに必要なcontrolファイルを編集したり、パッチの管理を行ったり、copyrightファイルを編集したりといった作業が行える。また、コマンドラインベースで同等の作業を行うこともできるという。
Debianパッケージに特化したツールじゃないんだけど。。。？ (スコア:2)
https://github.com/dod38fr/config-model/blob/master/README.pod [github.com] を見てもらうとわかるけど、一応「interactive configuration editor」を目指した設定ファイル編集のための汎用ツールなの。
で、それにDebianパッケージ用のプラグインが追加されたよ、という話。
＃debパッケージの作成はそんなに難しいとは感じない。通常のプログラム書くほうがよっぽど大変ですよ…。
Re:Debianパッケージに特化したツールじゃないんだけど。。。？ (スコア:1)
Debian関係者？
開発者の立場からすると開発の本体に集中したいのに、普及戦略の一貫とはいえDebian(もしくはUbuntu)という1ディストリビューションのためのややこしいルールを学ぶのは疲れます。
だいぶ前はこの辺をガマンしつつやってたんですが
といった楽な話を見聞きしたり体験したりするにつれ、比較的少人数で大量のパッケージングを管理するディストリビューションというシステムには無理があるというか不便な面も多いなと思う今日このごろです。 少なくとも若い人達は近付きたくないだろうし、なるべく近付かないで済むような技術やノウハウを作っていきたいものです。
Re: (スコア:0)
甘えんなよクズが。
苦労するのが嫌ならtarballだけ置いといて勝手にビルドしろと一行書いとけば？
どうなんだろう (スコア:0)
GUIしか使えない人用？
パッケージ作るぐらいの人ならGUI使わない人のほうが多い気もするけどね
マウスでカチカチやるよりコマンド叩いた方が早いんじゃなかろうか
キーボード VS マウス じゃないんだよ (スコア:1)
どうもGUIというと、マウスで～って言うように
入力デバイスの違いだって思う人が多いようですね（苦笑）
CUI（CLI）とGUIの違いは情報の表現力の違いですよ。
まずCLIの情報の表現力は著しく低い。
--helpでヘルプを表示することぐらいしかできない。
CUI（一行単位のコマンドラインのインターフェースじゃないもの）はCLIに比べれば情報の表現力が高い。
例えばテキストエディタのnanoや、ESCでメニューを表示するMS-DOSの一太郎みたいに
起動した段階で画面に何をすればいいかの情報を表示することが可能。
あとはメニューから候補を選んでいくだけで処理が実行できる。
CUIはマウスではなくキーボードで操作するけど、GUIに近い情報を表示することはできる。
この点でCLIよりも遥かにいい。ただし文字単位でしか情報を表示できない。色も文字単位。
GUIはCUIの表現力を更に発展させたもので、ドット単位で情報を表示できる。
だから文字以外の絵（アイコン）で情報を表示することも可能
情報の表現力の違いっていうのは正確には「最大」表現力なのでGUIでもCLIレベルの
使いにくいインターフェースになってしまうこともあるが、
最大の表現能力を備えたGUIでは工夫することでわかりやすいインターフェースを作ることができる。
工夫する余地が大きいのがGUI。GUIアプリを作るっていうのは、わかりやすいインターフェースに
なるように試行錯誤するってことで、試行錯誤の余地がないCLIより使いやすくなるのは当然。
GUIほどの表現能力があれば、何ができるのか？ 何をすべきなのか？ 何の情報が足りないのか？
といったことを編集中にリアルタイムに画像などを使ってわかりやすく提示することが可能になる。
ようするにCUI（CLI)の違いは入力デバイスの違いじゃなくて画面出力の情報の違いなんだよ。
CLIでもmanや--helpで情報が表示できるって？情報は多ければいいわけじゃない。
現在のコンテキスト（今やってること）に応じて、適切な情報だけを表示する方がいい。
CLIではこのコンテキストがないので長々とした情報をずらーっと表示することしか出来ない。
Re: (スコア:0)
ただ、GUI だと作業時点での情報しか表示されなくなりがちで、CUI だと作業の流れが見渡せるので(今は昔に比べて表示される行も多くなったしスクロールもほぼ無限に辿れる)、作業の流れのようなものを考えながら作業する場合は CUI の方が良いことも多い。
Re:キーボード VS マウス じゃないんだよ (スコア:1)
作業の流れが重要なのに、そういう情報が表示されないのなら、
GUIのデザインがダメなんじゃないだろうか。
偏見なんですが、ほぼCUIしか使わない人がGUIのアプリを作ると、
機能は詰め込みました、UIは考えていません。
って感じになるのが多いと思う。
Re: (スコア:0)
cliでも対話式にはできるし、どれだけ今必要な情報をシンプルに表現するかって意味でいくらでも工夫の余地がある。
Re: (スコア:0)
手間が掛かりすぎるのは割に合わないのでやらないとなりやすい。
で、独自の入れ方で何をどう入れたか他の人が分からなくて後で困る。
まあ実際そう言うことがあったから簡単に使えるようにするのは歓迎。
ドキュメントでカバーできる？じゃあ現状どうなのさ、できてねーじゃんってなるよ。
Re: (スコア:0)
> マウスでカチカチやるよりコマンド叩いた方が早いんじゃなかろうか
そう思います。しかも、スクリプト書くなりして自動化しやすいというメリットがありますね。
何をどうやったか確認したければ、スクリプトを見れば一目瞭然。
GUIだと気付かないようなメニューの奥の方とかの設定のせいで結果が違ってしまうこともあるので気を遣います。
Re: (スコア:0)
そして過信してredhatの中の人のように\rm -fr /しちゃうんですね
Re: (スコア:0)
> そして過信してredhatの中の人のように\rm -fr /しちゃうんですね
道具が強力であればあるほど、使い方を間違ったときのダメージも大きいのは仕方がありません。
それは、刃物や工具・交通手段や乗り物・化学薬品や燃料・高圧電源・熱源や調理器具・重機・化学プラントや発電所・武器など、何についても言えることです。
リスクが大きいと思えば、注意して使うとか、何らかの安全対策をとるとか、するものです。
それでも事故は起こるときには起こりますが。
Re: (スコア:0)
髭を剃るのにサバイバルナイフを使う愚かさを一般論でごまかすのですね
Re: (スコア:0)
正直、rm -rf ってやっちゃうのが怖くてCLIを使わないという結論に至った人なんて見たことないんですが。
Re: (スコア:0)
普通は適材適所で使いますからね
Re: (スコア:0)
SLが怖くてlsを使うだけで体が震えます。
Re: (スコア:0)
#2944038の内容をそのままお返しします
Re: (スコア:0)
一般論を装いつつGUIを排斥する偏ったコメントを指摘しているのですが？
私はもちろんどちらも使います
Re:どうなんだろう (スコア:1)
アビュースするものではないですが、たまたま遭遇したときはご褒美だと思う。
Re: (スコア:0)
私もどちらも使いますよ。
ただし、rm -rf / をやっちゃう可能性を排除するという目的でGUIを選択することはありませんし、
パッケージングならCLIを選びますね。
お絵かきならGUIを選びます。
Re: (スコア:0)
馬鹿を舐めるな。
Re: (スコア:0)
何らかの安全対策を取るとかの選択肢を示しておきながらGUIのツールを使うという選択肢だけは意地でも排除したいみたいですな。
別にあなた個人向けのツールでなし、そんなにムキにならんでも。フールプルーフも立派な機能の一つですよ。
そもそもこのツール、コマンドラインベースでも使えるようだし。
Re: (スコア:0)
馬鹿って誰のこと？私は自分の馬鹿さかげんは分かってるつもりだから舐めたりしない。
CLIでもGUIでも操作ミスは起こりうるし、それなりの注意を払って使えばそれでいい。
でも、rm -rf /してしまうのが怖いからCLIを使わないというのは、
それこそ、事故が怖いから自動車にも電車にも飛行機にも乗らないし道も歩きませんとか、
けがが怖いから刃物は一切使いませんとか言ってるようなもの。
Re: (スコア:0)
なんでそんなに自己中なの？自分ができることが馬鹿にもできると勘違いしてしまうくらい馬鹿なの？
Re: (スコア:0)
普段あんまりパッケージ作らない人用じゃないのか。
ていうか、自分も何かをインストールしたくても、
「パッケージ作るの面倒だなー、最近の経過追ってないしなー」
みたいな感じなので。
# プログラミング環境もあれこれ言われてたけど、GUI普及しましたね。
Re: (スコア:0)
毎回決まりきったオプションでやるならGUIの方がいいかもしれない。
Re: (スコア:0)
deb じゃなくて rpm だったけど、サーバ構築するときに
本番インストール時の手順を簡潔にするのと、
インストールパッケージを最低限に絞る（開発系を入れない）ために、
開発したプログラムをパッケージ化したことありますよ。
そういう用途なんじゃないのかな。
＃ 本番サーバに gcc入れたくないって言うのを不思議に思うひとには関係ない話だろうけど
Re: (スコア:0)
作成するスクリプト吐いてくれるとかじゃないのかな？
そうだったら最初の１回目にはよさそうだけど
Re: (スコア:0)
どんなスクリプトを吐いてくれるかによるかな。
複雑すぎて読みづらいスクリプトを吐いてくれても、あまりうれしくない。
吐いたスクリプトはそのまま使い、修正することはないというのなら、それでもいいけど。
ユーザは初心者でGUIを使ってるんだということを踏まえた、シンプルで必要十分で、初心者がその気になれば読んで勉強できるようなスクリプトを吐いてくれれば、役に立つと思う。
ただ、どうせスクリプトを勉強するのなら、手早く済ませるためのとっかかりとしては、GUIがなくてもスクリプトのテンプレートがあればそれでいいような気もする。
Re: (スコア:0)
「パッケージ作るぐらい」レベルの人にしか開かれていなかった作業がGUIによって開かれるのは、まあ良いことでは？
仕様を満たせるなら、どのツールを使おうと構わないんだし。
自分の作業を簡単にしてくれるツールが登場すると、なぜかそれをdisる人もいるけど不思議だよね。
パッケージメンテナ且つリポジトリ管理者として意見 (スコア:0)
Debianパッケージ作成は難しすぎると言っても過言じゃない。
守らないといけない規則は多いし、スクリプトによる過剰包装とか色々問題点がある。直接内容を記述する方式だとあまりにも冗長かつ非効率的だから、対話形式やGUIは欲しかった。
私は自前で自動的にリポジトリを作成するツールを作ってるけど、正直言って全部コマンドで良いっていう
上級者指向はやめてほしいね。
Re:パッケージメンテナ且つリポジトリ管理者として意見 (スコア:1)
「慈悲はない」も一言添えて欲しかった。
Re: (スコア:0)
ここに一票。Debianのパッケージ作成は「失敗」とか「インストールできるけど厳密に言えば構文エラー」とかいろいろ品質に差があるんだから、こんなのをコマンドでってのは頭おかしい。CUI派の言い分はGUIが人間に読める設定ファイル吐けばいいだけなんだから。
CMEと言えば先物取引市場だろ (スコア:0)
CMEと言えば主装置のことだろ (スコア:0)
CMEといえばCisco製IP-PBXのことだろJK
と思ってたら、いつの間にかCMEからCUCMEに変わってました。
Re: (スコア:0)
ラテンアルファベットというシステム自体に昔も今もある欠陥ですよ。
科学も漢字で表現する方法が発展すればどれだけ良かったか。
kとかiとか頭文字で表現するというのは本当にイライラする。
パッケージ管理くそくらえ (スコア:0)
従来のパッケージ管理システムは野良ビルドに冷たすぎる。
不要と判断したランタイムを勝手に削除してくれたり。
まるでtarボール解凍してmake installすることが
悪いことでもしてるみたい。
管理外のソフトウェアを見つけたら、
そっちを優先して欲しい。
Re: (スコア:0)
管理外のソフトウェアを見つけたら、
そっちを優先して欲しい。
せっかくの管理外も管理してほしいと言っているように見えますが…。いや、言いたいことはわかりますよ。
で、これは管理外パッケージから依存されているよ、と管理システムに教えるには
ダミーパッケージを作るのが古典かと。Debianなら equivs [debian.org]とか。
インチキでもパッケージを作ってしまうほうがいろいろ楽なことも。
make installを監視させてパッケージを作る
Re: (スコア:0)
あほ丸出し。
非プログラマーの非ソフトウェアのdebパッケージ (スコア:0)
そういうのを作りたい人がいるかもしれませんよ。
そういう人が、GUI版のパッケージ作成ツールが無いから
今までやっていなかったということもあり得ますよ。
理屈としては、debパッケージとして作成して
独自リポジトリーをDebian,Ubunut等向けとして公開すれば
顧客者などが、リポジトリーを追加してパッケージを導入すれば
随時、更新されるようなコンテンツを配布する手法として使えるはず。
たとえば、毎月新しい壁紙を配信!みたいなことができるかなぁ…