[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[debian-users:08788] Re: package documents & source package



佐野@浜松です。
御教示ありがとうございます。

[ささやまさん:]

> Debian Policy Manualによりますと、
...
> ということです。順序はともかく、書かなければいけないことに
> なっています。

先程、 www.debian.org にあった html 版を読んで確認しました。
なるほど、現在はこうなっているんですね。 bo の debian-policy
パッケージだと

5.3 Documentation and the changelog

   Document your changes and updates to the source package properly in
   the debian/changelog file.

   A copy of the file which will be installed in
   /usr/doc/package/copyright should be in debian/copyright.

しか無さそうな、、、と思っていたら、 binary package についての
説明のところにありました。

  3.2.7 /usr/doc/package/copyright

   This file must contain details of the authorship and copyright of the
   package. It must say where the upstream sources (if any) were
   obtained, and explain briefly what modifications were made in the
   Debian version of the package compared to the upstream one. It must
   name the original authors of the package and the Debian maintainer(s)
   who were involved with its creation.

   It must contain the full text of the copyright notice and any
   acknowledgements for the program and the licence terms under which the
...

   Do not use the copyright file as a general README file. If your
   package has such a file it should be installed in
   /usr/doc/package/README or README.Debian or some other appropriate
   place.

こっちの説明だと FAQ の雰囲気と違って、上流コードを入手した場所と
変更した部分が先にきて、上流開発者とパッケージメンテナーの名前、
そして最後に copyright notice という順番に書くのが自然という雰囲気
ですね。

一方、ささやまさんが教えて下さった現在の説明だと

5.6 Copyright information 

Every package must be accompanied by a verbatim copy of its copyright 
and distribution license in the file /usr/doc/<package-name>/copyright. 
This file must neither be compressed nor be a symbolic link.

となっていて、最初に "copyright and distribution license" の「丸写し」
を書くことになっているように読めます。続いて

In addition, the copyright file must say where the upstream sources 
(if any) were obtained, and explain briefly what modifications were 
made in the Debian version of the package compared to the upstream one. 
It must name the original authors of the package and the Debian
maintainer(s) who were involved with its creation.

この部分で、上流コードの入手場所と変更箇所の説明、それに上流開発者と
メンテナーの名前を「上記の著作権およびライセンス情報」に加えて記載する
となっているので、 bo 版の書き方と「順序」が変更になったかのような
印象を受けます。

[香田さん:]

> これが普通の書式だと思います。オリジナルの Copyrigt と
> 言ってもコピーするとか手が入っているのでしょうから
> どこにあるソースに含まれる Copyright を誰が引用したのか
> を明示している訳で問題とは思えませんが。
> ...
> 順序が問題でしょうか???

「彼」の主張によれば、「順序」が重要な問題らしいです。

ちょっと引用させてもらうと、

   The source was dowonloaded from ...
   Copyright:
   This package was debianized by ...

   こういう順番のほうが素直だと思うのは変ですか?
   頭に書いてあることほど情報に重みがあると思うのはおかしいんでしょうか。


   copyright 表示が必ずあるのは他のシステムには無い debian の優れた
   点の一つだと思います。
   しかし、やっぱり順番がおかしいと思う。

ということを書いていました。

# 実は職場のニュースグループでしばらく議論してた。 ^^;;

このへん、感覚的な部分があるように思うので、私にもよく理解はできて
いませんが、とりあえずそういう意見が (たぶん他にも) 存在するという
ことを認識したということです。で、仮にこの主張が誤解や偏見であると
いう立場を取るにしても、直接誤解を解く機会が得られない可能性を考慮
すると、無用な誤解を招くようなものは、それが本質的なものでなければ
排除したほうが良いのではないかと思いまして。

で、果してこの「順序」は Debian にとって本質的な問題なのか、どっち
でも良いことなのかということを質問させて頂いた次第です。

> ですから上に書いたように copyright に書いてある情報は
> パッケージ化に関する情報ではなく Copyright に関する情報
> だと思います。(誰がどこにあるソースから引用したかという)
> 私なんかはここに名前を見るとドキドキしてしまいます。
> 書かなくていいなら書きたくないのが本音です。

メンテナーのお仕事、御苦労さまです。今回の件は、けして貴重な努力を
注いで下さっているメンテナーの方々に文句をつけようなどという意思は
ありませんので、よろしくお願いします。

> 後でささやまさんが書かれているよう,全てに共通して含まれる
> のはオリジナルの Copyright ですよね。

ということは、これが copyright ファイルの中で最も重要な情報で
あると考えて良いのですね。

> # でも lynx でも gz は読めるはずですが。

これは良いことを聞きました。さっそく教えてあげることにします。 ^^)
実はこの件は、単に彼が diff ファイルを直接読むのに慣れていなかった
せいじゃないかと個人的には思うところもあったりします。

# ソースから make しようという人が diff くらい生で読めなくて
# どうする、っていう感覚。

> 最近は基本的なパッチを当てて orig.tar.gz を作ることに
> しています。ただ
> 
> * 「手元にあるオリジナルコード」は大抵何らかの修正している
> ことが多いのでどうせ make するにしてもオリジナルを取りなお
> さないといけない(パッチがすんなり当たらないなどで)。
> * パッチを当てるのも誰でもできるとはいえない。
> * diff.gz が大きくなる?
> 
> など少なくとも Debian 利用者には不都合はないような気が
> します。

私もほとんど Linux Only だし、 Slackware 使いの頃から
 Debian のソースを漁っていたくらいなので、特に「問題」
だと感じたことは無かったのですが、 *BSD 方面で使われている
 ports システムというのが、オリジナル (上流) のコードや
パッチをそのまま取り寄せてきて置いておく方式 (で、実際に
 make を実行する際にその場でそれらの展開とパッチ当てを
行なってから自前のパッチを適用する、という構成) になって
いるらしいのです。そして彼の主張によれば

   これは決して好き嫌いというだけではなく、資源の有効利用という観点から
   もそうあるべきだと思います。
    emacs なんて、どのシステムにもインストールしたいアプリケーションの
   一つですし、他の色々なシステムで一発 make できるようになっていますから、
   オリジナルのソースは色んな所から取ってこれます。
   普通は GNU のミラーから取ってくるんでしょうけど、FreeBSD の distfiles
   から取ってきても同じものが手に入ります。

    debian からだと、同じものだといわれても、なんか変わってそうで嫌です。
    debian から取ってきて IRIX でコンパイルするということは考えづらいです。

ということらしいです。もちろん、 dpkg / deb パッケージシステム
は Debian のために開発されたものなので、そのソースパッケージが
 dpkg システムに固有のものになっていてもおかしくないと私は思う
し、そもそも既にあるアプリケーションの「移植」を便利にするため
のシステムである (と思われる) ports とシステム管理をメインに
開発された deb パッケージシステムを比較すること自体間違っている
ような気もします。

ただ、既に ftp site などに存在している .tar.gz や .diff.gz を
そのまま使わずに .orig.tar.gz という形に変更して使うことにより
どういうメリットがあるのか、またはそうしなければならない理由と
いうものが何なのか、資料を探してもよくわからなかったので、この
場を借りて質問させて頂きました。

なお、上記の彼の主張は、以下に引用する私の意見への反論です。

  > しかし、同じものならば、ファイル名を変更するだけでなく、
  > ファイルサイズや日付まで変更するのはどうかと思いますけど。
  > 単なるミラーでいけない理由がよくわかりません。
  
  とりあえず、ソースパッケージを構成するファイルの数を少なくして
  わかりやすくした、という感じなのかもしれません。 XFree86 の場合の
  ように公開パッチがいくつか続いている場合、それらのパッチをすべて
  オリジナルのまま並べていくと、ファイルの数はどんどん増えていくこと
  になりますから。 Debian-JP の mule とか sendmail-wide なども既存の
  オリジナルソース + パッチを .orig.tar.gz にしていると思います。
  
   /usr/doc/debian/source-unpack.txt を読むと、昔は .orig 無しの tar.gz
  と diff.gz の 2 本立だったみたいですね。この場合は
  
  A. Old ones look like this:
        hello-1.3-4.tar.gz
        hello-1.3-4.diff.gz
   You unpack them by untarring the .tar.gz.  There is NO need to apply
   the diff.
  
  と書いてありますから、 tar.gz はパッチ適用済みの「 Debianize された」
  ソースの tar file だったのでしょう。さすがにそれではマズイということ
  で現在の
  
  B. New ones look like this:
        hello_1.3-11.dsc
        hello_1.3-11.diff.gz
        hello_1.3-11.orig.tar.gz - note the `.orig' part
   Here you MUST use dpkg-source or apply the diff manually - see below.
  
  ということになったのだろうと思います。ですから、今後さらにこの方向に進めば、
  将来的には木村さんのお好きな ports system のようにオリジナルをそのまま並べる
  という方向に行かないとも限りません。
  
  ただ、「 Debian パッケージのソースはあくまでも Debian システムの
  一部であって、オリジナルコードそのままではない」という考え方も
  あるかもしれませんから、確実にそうなるとも言えませんが。

# これを書いたあとで確認したのですが、 bo にある smail のソース
# パッケージは上の A. にある古い方式になってました。

-- 
 <sano@xxxxxxxxxxxxxxxxxxxxxxxxxx> : Taketoshi Sano (佐野 武俊)