すみませんが、質問させてください。
[Q1] やむにやまれぬ理由により、tracef
(http://binary.nahi.to/hogetrace/ )をdebian unstableで動作させ、手元で
パッケージ化をほぼ完了(※1)しました。で、
このバイナリはその仕様・機能から、x86系のlinuxカーネルのみで動作するもの
なのですが、こういう動作環境にいろいろ制約(特定CPUのみで、かつ、linux限
定とか)があるようなコマンドをパッケージ化してDDへアピールするのはあまり
よろしくないかんじでしょうか?雰囲気的にどんな感じでしょう?
(自分でちょこちょこgoogleで調べた幹事ですと、tracefと同様の手軽さで
利用でき、同様の機能と、実行性能を持つコマンドは、なかなか他に例がなさそ
うに見えます。)
[Q2] 諸事情であまりupstreamでメンテナンスされていない雰囲気のコマンドを
DDにアピールするのはdebian的にあまりよろしくない感じでしょうか?(確か
に、Bug Report 発生しても、upstreamに期待できないかもしれないし、将来
linux 3.Xになるあるいは,elf/dwarfの仕様が変わったりlibraryの仕様が変わっ
たり、CPUの動作が変わった時にはどうやっても動かなくなるかもしれない等)
すみませんが、どなたかこのあたり教えていただいてもよいでしょうか?
※1. 残りのタスクとしては、
(1) Readme(英語)作成と、
(2) Manページ(英語)と、
(3) 付属文章の英訳
(4) 作者に許可を取り付け
(5) ライセンス的にOKかどうかを固める(一部ライセンス不明らしき
コードが混ざってる...)
という大仕事があるのですが、ちょっと聞いてみました。
--
nozzy
2011-06-24 (金) の 00:24 +0900 に nozzy nozzy さんは書きました:
> [Q1] やむにやまれぬ理由により、tracef
> (http://binary.nahi.to/hogetrace/ )をdebian unstableで動作させ、手元で
> パッケージ化をほぼ完了(※1)しました。で、
> このバイナリはその仕様・機能から、x86系のlinuxカーネルのみで動作するもの
> なのですが、こういう動作環境にいろいろ制約(特定CPUのみで、かつ、linux限
> 定とか)があるようなコマンドをパッケージ化してDDへアピールするのはあまり
> よろしくないかんじでしょうか?雰囲気的にどんな感じでしょう?
こちらですが、実際そのようなパッケージで有名なものとして、そういえばKVM
がありましたね...
(x86系限定、linux限定)
なので、こちら問題ないということでOKなんですかね...なんかそういう気がし
てきました...
引き続き[Q2]をもしどなたかご存知の方よろしくお願いします。
---
nozzy
2011/6/24 nozzy nozzy <nozzy1...@gmail.com>:
> [Q2] 諸事情であまりupstreamでメンテナンスされていない雰囲気のコマンドを
> DDにアピールするのはdebian的にあまりよろしくない感じでしょうか?(確か
> に、Bug Report 発生しても、upstreamに期待できないかもしれないし、将来
> linux 3.Xになるあるいは,elf/dwarfの仕様が変わったりlibraryの仕様が変わっ
> たり、CPUの動作が変わった時にはどうやっても動かなくなるかもしれない等)
>
> すみませんが、どなたかこのあたり教えていただいてもよいでしょうか?
もし、本プログラムを使用されているのであれば、
似たような人やもしくはtracefプログラム自体を知らない人がいるかもしれません。
(少なくともぼくは知りませんでした)
なので、Debianに上げちゃっていいんではないでしょうか。
upstreamのサポート問題なのですが、もし期待できない場合には野島さんがサポートをする必要が出てくるかもしれません。
その点で勉強になって良かったりしないでしょうか。実際ぼくは良い勉強になりました。
> ※1. 残りのタスクとしては、
> (1) Readme(英語)作成と、
> (2) Manページ(英語)と、
> (3) 付属文章の英訳
> (4) 作者に許可を取り付け
> (5) ライセンス的にOKかどうかを固める(一部ライセンス不明らしき
> コードが混ざってる...)
> という大仕事があるのですが、ちょっと聞いてみました。
(5)は必須ですね。。。そこをクリアにするところから開始してはいかがでしょうか。
(5)でNGだと(1)~(4)が無駄骨になってしまうかもしれないので、、、
不明なことは作者の方に直接聞いた方が良いと思います。
パッケージメンテナとしての経験が浅いので、ツッコミがあったらよろしくお願いします。 >皆様
--
Kiwamu Okabe
以下に引用して応答します。
2011年6月24日10:36 Kiwamu Okabe <kiw...@debian.or.jp>:
> もし、本プログラムを使用されているのであれば、
> 似たような人やもしくはtracefプログラム自体を知らない人がいるかもしれません。
> (少なくともぼくは知りませんでした)
> なので、Debianに上げちゃっていいんではないでしょうか。
そういう考え方もありなんですね。なるほどです。
※ちょっと勝手が未だ見えなくて...
> upstreamのサポート問題なのですが、もし期待できない場合には野島さんがサポートをする必要が出てくるかもしれません。
> その点で勉強になって良かったりしないでしょうか。実際ぼくは良い勉強になりました。
さすがにtracefのupstreamとして動くのは、このプログラムの性格上、さすがにハードル高いなーと思うことしきりです。
※正直このプログラムは自分から見ると、いわゆる職人芸の塊にみえます。
>> ※1. 残りのタスクとしては、
>> (1) Readme(英語)作成と、
>> (2) Manページ(英語)と、
>> (3) 付属文章の英訳
>> (4) 作者に許可を取り付け
>> (5) ライセンス的にOKかどうかを固める(一部ライセンス不明らしき
>> コードが混ざってる...)
>> という大仕事があるのですが、ちょっと聞いてみました。
>
> (5)は必須ですね。。。そこをクリアにするところから開始してはいかがでしょうか。
> (5)でNGだと(1)~(4)が無駄骨になってしまうかもしれないので、、、
> 不明なことは作者の方に直接聞いた方が良いと思います。
>
ええ。ただ、自分はDDではないため、スポンサーがつかないとuploadできない状況ではあります。
また、何らかの理由で作者の方を混乱させる(あるいは何か期待させて裏切る)のは極力避けたいなー
と思ったりしてます。なので、少なくともdebian側で何かまずいことがないかどうかを先に
確かめておこうかなーと思ったりしました。
自分もパッケージ初心者なのでよくわかってない事も多いです...
--
nozzy
Debianの文章をよくよく読んでみると、なんとなくですが、Debianのパッケージ
は対象ソフトのライセンスが問題がなければ、パッケージ化してもDebian的には
問題ないよ?という感じに見えてきました。
で、万一、パッケージ化できない事態が生じる(例:kernelのバージョンが大幅
に変わって動かなくなっちゃったが、upstreamの代わりに保守するのも技術難易
度が高すぎて困難)とかの状態になっちゃった場合の終わらせ方が判ればよいの
かな?という気がしてきました。
つきましては、以下の質問をします。
[Q] パッケージ化が困難になってしまった場合のパッケージ化の終わらせ方って
何か情報ってありますでしょうか?
※upstreamが対応を断念しており、パッケージメンテの引き継ぎもできなそうな
感じの場合を想定します。
こちら何か情報などありましたらお願いします。質問ばかりですみませんが、
よろしくお願いします。
--
Nozzy
2011-06-25 (土) の 02:29 +0900 に nozzy nozzy さんは書きました:
On Fri, 24 Jun 2011 00:24:44 +0900
nozzy nozzy <nozzy1...@gmail.com> wrote:
> このバイナリはその仕様・機能から、x86系のlinuxカーネルのみで動作するもの
> なのですが、こういう動作環境にいろいろ制約(特定CPUのみで、かつ、linux限
> 定とか)があるようなコマンドをパッケージ化してDDへアピールするのはあまり
> よろしくないかんじでしょうか?雰囲気的にどんな感じでしょう?
http://www.debian.org/doc/manuals/developers-reference/pkgs.html#packages-arch-specific
あたりでチラッと話は出てます(査読者募集中…)。
私の見方ですが、当然あらゆるアーキテクチャで動作する方がよいには
決まっていますが、制約があるものはそれはそれで仕方ないと思います。
> [Q2] 諸事情であまりupstreamでメンテナンスされていない雰囲気のコマンドを
> DDにアピールするのはdebian的にあまりよろしくない感じでしょうか?(確か
> に、Bug Report 発生しても、upstreamに期待できないかもしれないし、将来
> linux 3.Xになるあるいは,elf/dwarfの仕様が変わったりlibraryの仕様が変わっ
> たり、CPUの動作が変わった時にはどうやっても動かなくなるかもしれない等)
http://www.debian.org/doc/manuals/developers-reference/beyond-pkging.html
あたりで雰囲気は掴めるかな、と思いますがどうでしょうか。
> 開発元のコードは成熟していて、セキュリティホールの山ではないですか?
> 同じことができる既存パッケージがありませんか? そしてこの新しいパッケージと
> 比べてどうですか? 新しいパッケージはユーザから要求されたものですか? そして
> ユーザ数はどの程度の大きさですか? 大本の開発者らはアクティブですか?
upstreamがアクティブじゃないのは良くは無いですが、どの程度のリスクになる
のか。ここの判断は一概には言えないと思います(少なくとも上記の問いかけに
考える必要はあるかと思います)。
--
Regards,
Hideki Yamane henrich @ debian.or.jp/org
http://wiki.debian.org/HidekiYamane
・まずはTags: help でバグ登録しておき、メーリングリスト等で助けを求める
・ダメなら Orphan か パッケージを削除する、ですかね。
削除の場合は、ftp.debian.org 擬似パッケージに RM バグ登録します。
以下、登録サンプル。
> To: sub...@bugs.debian.org
> Subject: RM: ttf-umefont -- ROM; migrate to new package name
>
> Package: ftp.debian.org
> Severity: normal
>
> <snip>
削除する場合は経緯がわかるようにしておくのが親切かと思います。
> [Q] パッケージ化が困難になってしまった場合のパッケージ化の終わらせ方って
> 何か情報ってありますでしょうか?
そのような疑問が生じた場合、まずは『Debian ポリシーマニュアル』と
『デベロッパーズリファレンス』を調べてみることをお勧めします。
Debian 開発者のコーナー
http://www.debian.org/devel/
Debian ポリシーマニュアル
http://www.debian.org/doc/debian-policy/
このマニュアルには、Debian GNU/Linux ディストリビューションが 守るべ
き方針が書かれています。Debian アーカイブの構造と内容、 オペレーティ
ングシステムの設計に関するいくつかの事項、 個々のパッケージがディス
トリビューションに含まれるために 満たさなければならない技術的な必要
事項などが含まれます。
つまり、あなたはこれを読む必要があります。
デベロッパーズリファレンス
http://www.debian.org/doc/manuals/developers-reference/
このドキュメントの目的は、Debian 開発者に、推奨される手順と 利用でき
るリソースの概要を提供することです。もう一つの 必読文書です。
5.9. パッケージの移動、削除、リネーム、変更、みなしご化
http://www.debian.org/doc/manuals/developers-reference/pkgs.ja.html#archive-manip
http://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#archive-manip
--
木下達也
野島です。引用の情報ありがとうございます。
確かに記載がありました。野島の読み取りが甘かった模様です。大変助かりま
した。
※不要になったライブラリの削除等、という例が一緒に掲載されていたため、前
向きな理由のときにのみ適用する話かと思い込んでました。動作について
upstreamも対応不能、パッケージメンテナも対応不能という、かなり後ろ向きな
場合の手段としても使える事に気がついてませんでした...すみません。
--
Nozzy
2011-06-25 (土) の 22:57 +0900 に Tatsuya Kinoshita さんは書きました:
野島です。いつもお世話になっております。
引用の件情報ありがとうございます。具体的にはどうすると言う情報大変たすか
りました。
2011-06-25 (土) の 22:40 +0900 に Hideki Yamane さんは書きました:
野島です。お世話になっております。
> > 開発元のコードは成熟していて、セキュリティホールの山ではないですか?
> > 同じことができる既存パッケージがありませんか? そしてこの新しいパッケージと
> > 比べてどうですか? 新しいパッケージはユーザから要求されたものですか? そして
> > ユーザ数はどの程度の大きさですか? 大本の開発者らはアクティブですか?
>
> upstreamがアクティブじゃないのは良くは無いですが、どの程度のリスクになる
> のか。ここの判断は一概には言えないと思います(少なくとも上記の問いかけに
> 考える必要はあるかと思います)。
なるほどです。了解しました。情報ありがとうございました。
パッケージ化にあたって、こちら留意するようにします。
---
Nozzy
野島です。
> > ※1. 残りのタスクとしては、
> > (1) Readme(英語)作成と、
> > (2) Manページ(英語)と、
> > (3) 付属文章の英訳
> > (4) 作者に許可を取り付け
> > (5) ライセンス的にOKかどうかを固める(一部ライセンス不明らしき
> > コードが混ざってる...)
> > という大仕事があるのですが、ちょっと聞いてみました。
>
> (5)は必須ですね。。。そこをクリアにするところから開始してはいかがでしょうか。
> (5)でNGだと(1)〜(4)が無駄骨になってしまうかもしれないので、、、
> 不明なことは作者の方に直接聞いた方が良いと思います。
>
現在、皆様からいただいた情報を元に、(4)を行ったところ、作者の宛先が不明
な状態であった(ホームページにあったupstreamへの連絡先へ問い合わせしたと
ころ、user unkownのメールが返ってきた...)
状況になりました。(5)についてはGPLであった事が確認できました。
こりゃ、一筋縄ではいかなさそうです...
このプログラムのupstreamの方は、鵜飼さんと一緒にBinary Hacksという本出し
ている人みたいなのですが、なにか連絡手段ってあるものなんでしょうか
ね...こういうとき...
※debian unstableで動くようにいろいろパッチ作ったのですが...うーん。
---
Nozzy
ちょっぴり状況変わりました。
tracefの配布先ホームページにtracefの作者のtwitterアカウントをみつけ、
この記載内容とgoogle使って別の連絡先を発見し、こちらに今連絡とってます。
応答あるといいな...
2011-06-26 (日) の 23:59 +0900 に nozzy nozzy さんは書きました:
2011年6月26日14:59 nozzy nozzy <nozzy1...@gmail.com>:
何の許可を取ろうとしていますか?英訳したマニュアルについてでしょうか。
英訳したマニュアルをupstreamに取り込んでもらうことは良いことですが、
別に取り込まれなくてもDebianパッケージとして頒布できます。
(ライセンスに問題がなければ、ですが。)
取り込んでもらうための作業は別に後回しても良いと思います。
ようするに並行して作業できるということです。
岩松
--
Nobuhiro Iwamatsu
iwamatsu at {nigauri.org / debian.org}
GPG ID: 40AD1FA6
野島です。いつもお世話になっております。
> 何の許可を取ろうとしていますか?英訳したマニュアルについてでしょうか。
> 英訳したマニュアルをupstreamに取り込んでもらうことは良いことですが、
> 別に取り込まれなくてもDebianパッケージとして頒布できます。
> (ライセンスに問題がなければ、ですが。)
>
> 取り込んでもらうための作業は別に後回しても良いと思います。
> ようするに並行して作業できるということです。
アドバイスありがとうございます。取り急ぎ許可をとろうとしているのは、
tracefコマンドをdebianパッケージにしてdebianに取り込む可能性があるがよい
か?
という許可となります。
いちおうGPLなプログラムですが、幸いにしてdebianパッケージに入り配布物
として扱われた場合、
(1) 少なからずdebianのBUG報告が間違ってupstreamへやってくる可能性が
あり、
(2) 配布物へ何らかのupstreamへの連絡先の記載を入れる(SPAM避けとして
XXX_at_XXX_dot_XXX みたいな連絡先ではなく、X...@XXX.XXXとして記載すると
か)
などなどupstreamとして意図しない事態になった場合にもめないようにしたく考
えております。
どんなもんでしょう?
---
Nozzy
2011年6月27日1:34 nozzy nozzy <nozzy1...@gmail.com>:
私の意見としては、わざわざそのような事は気にしなくてもよいと思います。
インターネットで公開している以上、上のような問題はDebain関係ありなしに関わらず起こる事なので。
ただ、私が新しいパッケージをDebianにアップロードしたときは、
「Debian にアップロードしました。今後とも宜しく。」というメールは送っています。
野島です。毎度お世話になります。
2011-06-27 (月) の 11:23 +0900 に Nobuhiro Iwamatsu さんは書きました:
> > などなどupstreamとして意図しない事態になった場合にもめないようにしたく考
> > えております。
> >
> > どんなもんでしょう?
> >
>
> 私の意見としては、わざわざそのような事は気にしなくてもよいと思います。
> インターネットで公開している以上、上のような問題はDebain関係ありなしに関わらず起こる事なので。
>
確かにそうなんですよね...こちらの意見にはDebian相手であれば賛同したいと
ころではあります。(そもそもupstreamのソースに上から下までGPLが適用され
ているわけで...)
※いや、その。自分の知り合い(IT業界営業経験あり)に相談したところ
「upstreamに連絡とった方がいいって。そうしないと心証悪いかもよー?連絡と
れないったってtracefの作者って出版とか関わってるでしょ?最悪出版関係から
アプローチとかそこまでちゃんとしたの?」と指摘受けまして...逆に、海外の
人に聞くと真逆で「おまえは何をいってるんだ??GPLだろ?GPLの意味分かって
る?GPL適用してんだからさっさとパッケージにしていいにきまってるだろ?」み
たいに扱われました。この手の感覚って海外と日本で結構違うんだなーと思った
り思わなかったり...
> ただ、私が新しいパッケージをDebianにアップロードしたときは、
> 「Debian にアップロードしました。今後とも宜しく。」というメールは送っています。
>
あと何回か連絡送って応答なかったら、海外の例にならって、そうしようかなー
と思うこのごろです。
※自分としては、バイナリの実行トレーサに関して、tracef並に手軽に利用でき
るような他の実装をしらないので...これはOSSの逆解析に非常に強力なツールと
思ってます。(関数ポインタ、virtualメソッド、ダイナミックリンクでガンガ
ン等、ソースからだけじゃまったく動作わからんぞーと言うときの強力な兵器と
なりうるので、どうにもパッケージ化したいところではあります)
--
Nozzy
特にアップストリームの事前許可はいらないのは同感です。挨拶は出しておいて、
返事が1週間してもなければ、さっさとアップして、「アップしました。今後とも
よろしく」でもいい感じがします。きっとお忙しいだけなので。
> あと何回か連絡送って応答なかったら、海外の例にならって、そうしようかなー
> と思うこのごろです。
ただ注意すべきは、メールに返事が無いようではUPSTREAMの迅速なサポートが今後
とも期待できないということです。
挑戦的な態度をこちらからとることは無いのですが、相手がどう出るか分からない
のは、海外でもcdrecord (cdrkit/wodim)の経緯を見れば明らかです。結局フォーク
していますよね、相手が敵対的で難しかったので。日本人的挨拶文化の問題では無い
ですが。。。
Debianの基本は、敵対的アップストリームのパッケージにはその必要性を吟味し
細心の注意をするということがあります。
ただパッケージするだけでなく、aliothのcollab-maintにパッケージ全体のgit
でもあとで作ると、今後いろんな人とコードに改変を加える際に良いかも知れま
せんね。
よろしく。
青木