パスワードを忘れた? アカウント作成
12639567 story
Debian

Debianパッケージ作成支援ツール「cme」登場、GUIでの操作も可能 40

ストーリー by hylom
使ってみよう 部門より
insiderman 曰く、

Debian向けのパッケージ(.debファイル)作成を支援するGUIツール「cme」なるものが登場した模様(Phoronix)。Managing Debian packages with cmeなるドキュメントも公開されている。

Debianパッケージを作成するにはいくつかのやり方があり、柔軟にパッケージ作成を行えるいっぽう、柔軟すぎて学習のハードルは高かった。Debianパッケージに必要なcontrolファイルを編集したり、パッチの管理を行ったり、copyrightファイルを編集したりといった作業が行える。また、コマンドラインベースで同等の作業を行うこともできるという。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • https://github.com/dod38fr/config-model/blob/master/README.pod [github.com] を見てもらうとわかるけど、一応「interactive configuration editor」を目指した設定ファイル編集のための汎用ツールなの。

    で、それにDebianパッケージ用のプラグインが追加されたよ、という話。

    #debパッケージの作成はそんなに難しいとは感じない。通常のプログラム書くほうがよっぽど大変ですよ…。

    • #debパッケージの作成はそんなに難しいとは感じない。通常のプログラム書くほうがよっぽど大変ですよ…。
      Debian関係者?

      開発者の立場からすると開発の本体に集中したいのに、普及戦略の一貫とはいえDebian(もしくはUbuntu)という1ディストリビューションのためのややこしいルールを学ぶのは疲れます。
      • 自作の人気が出てないソフトの場合は自分でやらないといけない(そして何か間違って迷惑をかける)
      • (国内の場合)不人気ソフトの開発者は直接Debian開発者にパッケージングをお願いをすると良いが、開発者に当たり外れがある
      • パッケージングする人がソフトの動作をイマイチ理解してくれてない
      • 人気が出るとDebianの人がやってくれるが、これをshared libraryにとか、この設定ファイルはここにとか色々言ってくる
      • 色々といじられてQAしたのとは違う環境で動かされ、変なバグレポートが降ってくる

      だいぶ前はこの辺をガマンしつつやってたんですが

      • 今時はDockerfileを書くのが安易
      • PythonやRubyのPIP, GEMのようなセルフサービスの方が人を通さないだけ便利
      • (自由ではないけど)iTunes storeやPlay storeなんかは超楽ちん
      • Webアプリだとすぐにユーザーに新しいバージョンを提供できる

      といった楽な話を見聞きしたり体験したりするにつれ、比較的少人数で大量のパッケージングを管理するディストリビューションというシステムには無理があるというか不便な面も多いなと思う今日このごろです。 少なくとも若い人達は近付きたくないだろうし、なるべく近付かないで済むような技術やノウハウを作っていきたいものです。

      親コメント
      • by Anonymous Coward
        自分のソフトを広めたいと思うから苦労するんだろ?
        甘えんなよクズが。
        苦労するのが嫌ならtarballだけ置いといて勝手にビルドしろと一行書いとけば?
  • by Anonymous Coward on 2016年01月04日 16時11分 (#2943988)

    GUIしか使えない人用?
    パッケージ作るぐらいの人ならGUI使わない人のほうが多い気もするけどね

    マウスでカチカチやるよりコマンド叩いた方が早いんじゃなかろうか

    • by Anonymous Coward on 2016年01月05日 9時59分 (#2944255)

      どうも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ではこのコンテキストがないので長々とした情報をずらーっと表示することしか出来ない。

      親コメント
      • by Anonymous Coward

        ただ、GUI だと作業時点での情報しか表示されなくなりがちで、CUI だと作業の流れが見渡せるので(今は昔に比べて表示される行も多くなったしスクロールもほぼ無限に辿れる)、作業の流れのようなものを考えながら作業する場合は CUI の方が良いことも多い。

      • by Anonymous Coward

        cliでも対話式にはできるし、どれだけ今必要な情報をシンプルに表現するかって意味でいくらでも工夫の余地がある。

    • by Anonymous Coward

      手間が掛かりすぎるのは割に合わないのでやらないとなりやすい。
      で、独自の入れ方で何をどう入れたか他の人が分からなくて後で困る。

      まあ実際そう言うことがあったから簡単に使えるようにするのは歓迎。
      ドキュメントでカバーできる?じゃあ現状どうなのさ、できてねーじゃんってなるよ。

    • by Anonymous Coward

      > マウスでカチカチやるよりコマンド叩いた方が早いんじゃなかろうか

      そう思います。しかも、スクリプト書くなりして自動化しやすいというメリットがありますね。

      何をどうやったか確認したければ、スクリプトを見れば一目瞭然。
      GUIだと気付かないようなメニューの奥の方とかの設定のせいで結果が違ってしまうこともあるので気を遣います。

      • by Anonymous Coward

        そして過信してredhatの中の人のように\rm -fr /しちゃうんですね

        • by Anonymous Coward

          > そして過信してredhatの中の人のように\rm -fr /しちゃうんですね

          道具が強力であればあるほど、使い方を間違ったときのダメージも大きいのは仕方がありません。
          それは、刃物や工具・交通手段や乗り物・化学薬品や燃料・高圧電源・熱源や調理器具・重機・化学プラントや発電所・武器など、何についても言えることです。

          リスクが大きいと思えば、注意して使うとか、何らかの安全対策をとるとか、するものです。
          それでも事故は起こるときには起こりますが。

          • by Anonymous Coward

            髭を剃るのにサバイバルナイフを使う愚かさを一般論でごまかすのですね

            • by Anonymous Coward

              正直、rm -rf ってやっちゃうのが怖くてCLIを使わないという結論に至った人なんて見たことないんですが。

              • by Anonymous Coward

                普通は適材適所で使いますからね

              • by Anonymous Coward

                SLが怖くてlsを使うだけで体が震えます。

              • by Anonymous Coward

                #2944038の内容をそのままお返しします

              • by Anonymous Coward

                一般論を装いつつGUIを排斥する偏ったコメントを指摘しているのですが?

                私はもちろんどちらも使います

              • アビュースするものではないですが、たまたま遭遇したときはご褒美だと思う。

                親コメント
              • by Anonymous Coward

                私もどちらも使いますよ。

                ただし、rm -rf / をやっちゃう可能性を排除するという目的でGUIを選択することはありませんし、
                パッケージングならCLIを選びますね。
                お絵かきならGUIを選びます。

              • by Anonymous Coward

                馬鹿を舐めるな。

              • by Anonymous Coward

                何らかの安全対策を取るとかの選択肢を示しておきながらGUIのツールを使うという選択肢だけは意地でも排除したいみたいですな。
                別にあなた個人向けのツールでなし、そんなにムキにならんでも。フールプルーフも立派な機能の一つですよ。
                そもそもこのツール、コマンドラインベースでも使えるようだし。

              • by Anonymous Coward

                馬鹿って誰のこと?私は自分の馬鹿さかげんは分かってるつもりだから舐めたりしない。
                CLIでもGUIでも操作ミスは起こりうるし、それなりの注意を払って使えばそれでいい。

                でも、rm -rf /してしまうのが怖いからCLIを使わないというのは、
                それこそ、事故が怖いから自動車にも電車にも飛行機にも乗らないし道も歩きませんとか、
                けがが怖いから刃物は一切使いませんとか言ってるようなもの。

              • by Anonymous Coward

                なんでそんなに自己中なの?自分ができることが馬鹿にもできると勘違いしてしまうくらい馬鹿なの?

    • by Anonymous Coward

      普段あんまりパッケージ作らない人用じゃないのか。
      ていうか、自分も何かをインストールしたくても、
      「パッケージ作るの面倒だなー、最近の経過追ってないしなー」
      みたいな感じなので。

      # プログラミング環境もあれこれ言われてたけど、GUI普及しましたね。

      • by Anonymous Coward

        毎回決まりきったオプションでやるならGUIの方がいいかもしれない。

      • by Anonymous Coward

        deb じゃなくて rpm だったけど、サーバ構築するときに
        本番インストール時の手順を簡潔にするのと、
        インストールパッケージを最低限に絞る(開発系を入れない)ために、
        開発したプログラムをパッケージ化したことありますよ。

        そういう用途なんじゃないのかな。

        # 本番サーバに gcc入れたくないって言うのを不思議に思うひとには関係ない話だろうけど

    • by Anonymous Coward

      作成するスクリプト吐いてくれるとかじゃないのかな?
      そうだったら最初の1回目にはよさそうだけど

      • by Anonymous Coward

        どんなスクリプトを吐いてくれるかによるかな。

        複雑すぎて読みづらいスクリプトを吐いてくれても、あまりうれしくない。
        吐いたスクリプトはそのまま使い、修正することはないというのなら、それでもいいけど。

        ユーザは初心者でGUIを使ってるんだということを踏まえた、シンプルで必要十分で、初心者がその気になれば読んで勉強できるようなスクリプトを吐いてくれれば、役に立つと思う。

        ただ、どうせスクリプトを勉強するのなら、手早く済ませるためのとっかかりとしては、GUIがなくてもスクリプトのテンプレートがあればそれでいいような気もする。

    • by Anonymous Coward

      「パッケージ作るぐらい」レベルの人にしか開かれていなかった作業がGUIによって開かれるのは、まあ良いことでは?
      仕様を満たせるなら、どのツールを使おうと構わないんだし。
      自分の作業を簡単にしてくれるツールが登場すると、なぜかそれをdisる人もいるけど不思議だよね。

  • Debianパッケージ作成は難しすぎると言っても過言じゃない。
    守らないといけない規則は多いし、スクリプトによる過剰包装とか色々問題点がある。直接内容を記述する方式だとあまりにも冗長かつ非効率的だから、対話形式やGUIは欲しかった。
    私は自前で自動的にリポジトリを作成するツールを作ってるけど、正直言って全部コマンドで良いっていう
    上級者指向はやめてほしいね。

  • by Anonymous Coward on 2016年01月04日 18時55分 (#2944070)
    検索しにくい単語を当てるもんじゃないわ
    • CMEといえばCisco製IP-PBXのことだろJK
      と思ってたら、いつの間にかCMEからCUCMEに変わってました。

    • by Anonymous Coward

      ラテンアルファベットというシステム自体に昔も今もある欠陥ですよ。
      科学も漢字で表現する方法が発展すればどれだけ良かったか。
      kとかiとか頭文字で表現するというのは本当にイライラする。

  • by Anonymous Coward on 2016年01月04日 21時47分 (#2944122)

    従来のパッケージ管理システムは野良ビルドに冷たすぎる。
    不要と判断したランタイムを勝手に削除してくれたり。

    まるでtarボール解凍してmake installすることが
    悪いことでもしてるみたい。

    管理外のソフトウェアを見つけたら、
    そっちを優先して欲しい。

    • by Anonymous Coward

      管理外のソフトウェアを見つけたら、
      そっちを優先して欲しい。

      せっかくの管理外も管理してほしいと言っているように見えますが…。いや、言いたいことはわかりますよ。

      で、これは管理外パッケージから依存されているよ、と管理システムに教えるには
      ダミーパッケージを作るのが古典かと。Debianなら equivs [debian.org]とか。

      インチキでもパッケージを作ってしまうほうがいろいろ楽なことも。
      make installを監視させてパッケージを作る

    • by Anonymous Coward

      あほ丸出し。

  • by Anonymous Coward on 2016年01月06日 0時21分 (#2944718)

    そういうのを作りたい人がいるかもしれませんよ。
    そういう人が、GUI版のパッケージ作成ツールが無いから
    今までやっていなかったということもあり得ますよ。

    理屈としては、debパッケージとして作成して
    独自リポジトリーをDebian,Ubunut等向けとして公開すれば

    顧客者などが、リポジトリーを追加してパッケージを導入すれば
    随時、更新されるようなコンテンツを配布する手法として使えるはず。

    たとえば、毎月新しい壁紙を配信!みたいなことができるかなぁ…

typodupeerror

開いた括弧は必ず閉じる -- あるプログラマー

読み込み中...