web-dev-qa-db-ja.com

異なるパッケージに同じソースコードを含めるにはどうすればよいですか？

私は最近、apt-get sourceを使用して特定のパッケージのソースコードを取得するのがいかに簡単かを学びました。これにより、ソースコードを取得し、変更を加えて、任意のパッケージの独自の修正バージョンをインストールできます。これは素晴らしい！

今日まで、私は各パッケージに独自のソースコードがあり、異なるパッケージには異なるソースコードがあると想定していました。

しかし、今私は異なるパッケージが同じソースコードを持つことができることを発見しました。以下にその例を示します。

次の4つのパッケージは同一のソースコードを持っているようです：

gir1.2-mutter-4
libmutter-4-0
mutter
mutter-common

4つすべてが私のUbuntu 19.04コンピュータにインストールされています。 apt-get source gir1.2-mutter-4を実行すると、apt-get source libmutter-4-0とまったく同じ結果が得られます。また、mutterおよびmutter-commonパッケージも同様です。

確認方法は次のとおりです。

mkdir a
cd a
apt-get source gir1.2-mutter-4
cd ..
mkdir b
cd b
apt-get source libmutter-4-0
cd ..
diff -r a b

上記の最後の行の再帰的diffは出力を提供せず、ディレクトリの内容が同じであることを示しています。

今私の質問へ：どのようにして異なるパッケージが同じソースコードを持つことができますか？

これが意図したものであり、なんらかのエラーではないと仮定すると、パッケージ間の違いは何ですか？どのようにしてその違いを確認できますか？

ソースコードの構成とコンパイルの方法がパッケージによって異なる可能性があります。コードのさまざまな部分がさまざまなパッケージに含まれていますか？その場合、各パッケージの構成方法に関する情報はどこにありますか？

編集：これをテストする場合は、追加するのを忘れており、apt-get sourceを適切に機能させるには、ここで説明するように、最初にsoftware-properties-gtkを使用して有効にする必要がある場合があります https://askubuntu.com/a/857433/874649

編集2：優れた回答をありがとう！私はこれも役に立ちました https://askubuntu.com/a/246721/874649 -非常に便利なapt-get build-depおよびdpkg-buildpackageコマンドについて。ソースパッケージのソースコードを変更した後、dpkg-buildpackage -us -ucを使用して、変更したプログラムのインストールに使用できる新しい.debファイルを構築できます。

package-managementsoftware-installationpackaging
40
Elias

ビルドされたバイナリパッケージと、パッケージのビルド元のソースコード/パッケージを混同している。

参照しているパッケージはすべて、同じソースコード/パッケージmutterからビルドされています。 packages.ubuntu.comにアクセスして、見ているパッケージを検索し、それが参照する「ソースパッケージ」を参照することで、簡単に見つけることができます。この場合はmutterです。

enter image description here

ただし、そこから Mutterのソースパッケージのランチパッドページ を確認して、多数のバイナリパッケージがビルドされることを確認できます（インストール用にビルドされたコンパイル済みソースコードなど）：

enter image description here

これらの説明は、各パッケージに含まれる/インストールされる内容を説明しています。指定した4つのパッケージに焦点を当て、次の説明を使用します。

  • gir1.2-mutter-4-MutterのGObjectイントロスペクションデータ（girとGObjectがMutterとGObjectの相互作用のライブラリー/データとして使用）
  • libmutter-4-0-ムッターウィンドウマネージャーの基盤となるライブラリ。 （通常、プラグイン開発、開発およびMutter統合のコンパイルなどに使用されます）
  • mutter-GNOMEのウィンドウマネージャーライブラリを使用する実際のMutterウィンドウマネージャー（これがGObjectが必要な理由です）
  • mutter-common-Mutterの共有ファイル-通常、デフォルトの構成オプションまたはソースパッケージからビルドされたallパッケージに共通のアイテム。

パッケージリストに表示されているのは、同じソースコードに由来するビルドされたパッケージです-各パッケージは異なりますアイテムは、ビルド/コンパイル後にインストールされ、さまざまな用途に使用されます。個々のパッケージをダウンロードし、U7のp7Zipまたは組み込みのArchive Managerを使用してそれらにアクセスし、各パッケージに含まれる内容の違いを確認することで、パッケージ自体の内容を確認できます仕方。 これは言いました、それらはすべて同じソースコードに由来します-彼らは単にインストールされている異なるアイテムを含んでいますシステムへ。

42
Thomas Ward

ソースパッケージとバイナリパッケージは別々に存在します。各ソースパッケージには、複数のバイナリパッケージが関連付けられている場合があります。つまり、同じソースパッケージから複数のバイナリパッケージをビルドすることができます。

これが発生する一般的な方法の1つは、プログラム、そのプログラムが多くの作業を行うために使用するライブラリ、それをコンパイルするために使用されるヘッダーファイル、およびそのライブラリを使用する他の（おそらくは）プログラムを使用することです。これらはすべて同じソースツリーで開発および保守され、DebianまたはUbuntuパッチの有無にかかわらず、ソースパッケージを生成するために使用されます。次に、そのソースパッケージを使用して、プログラム、ライブラリ、ヘッダーの個別のバイナリパッケージをビルドします。

それがここにあります（他のいくつかのバイナリパッケージも同様です）。 apt sourceコマンドで異なるバイナリパッケージを指定しましたが、コマンドは同じソースパッケージをダウンロードして解凍しています。

これは、パッケージ名をapt sourceに渡したが、その名前のソースパッケージがない場合、それをバイナリパッケージの名前として扱い、そのバイナリパッケージの対応するソースパッケージが必要であると想定するために発生します。

LaunchpadのUbuntuのメインページ では、パッケージを検索できます。ランチパッドは、ソースパッケージに関する情報を表示します（一方 buntu Packages Search は、バイナリパッケージに関する情報を表示します）。 mutter を検索すると、 トーマスウォードが言ったように あなた' buntuのmutterソースパッケージのLaunchpadページ が見つかります。これは、どのバイナリパッケージがソースパッケージに対応するかを確認する1つの方法です。そのページの上部近くに、それは言う：

ubuntuのmutterパッケージ

gir1.2-mutter-4：MutterのGObjectイントロスペクションデータ
libmutter-4-0：Mutterウィンドウマネージャーのウィンドウマネージャーライブラリ
libmutter-4-0-dbgsym：ubuntu eoanのlibmutter-4-0-dbgsymに関する要約はありません。
libmutter-4-dev：Mutterウィンドウマネージャーの開発ファイル
mutter：GNOMEのウィンドウマネージャーライブラリを使用したウィンドウマネージャーの例
mutter-common：ムターウィンドウマネージャーの共有ファイル
mutter-dbgsym：mutterのデバッグシンボル

バイナリパッケージがビルド元のソースパッケージと同じ名前を持たない場合でも、通常、ランチパッドでバイナリパッケージを検索することにより、そのソースパッケージを見つけることができます。

多くの場合、バイナリパッケージの名前を調べることにより、バイナリパッケージとそれをビルドするために使用されるソースパッケージの関係を知ることができます。

  • libで始まるバイナリパッケージ名は、通常、複数のプログラム（将来のプログラムを含む）で使用できるコードのライブラリを提供します。

  • -devで終わるものは ヘッダーファイル を提供し、ライブラリを使用するソースコードのコンパイルを容易にします。

  • -dbgまたは-dbgsymで終わるものは デバッグシンボル を提供します（つまり、libmutter-4-0-dbgsymは現在要約を表示していませんが、デバッグシンボルパッケージであることがわかります）。 。

  • -commonで終わるファイルは、/usr/shareにあるファイル（多くの場合、データファイル）を提供する傾向があります。このようなファイルは、静的で宣言的な形式のコードである場合がありますが、自然な（つまり人間の）言語へのインターフェース変換を提供する場合もあります。このようなパッケージで何ができるかについては、それほど制限はありません。

    mutter の場合、-commonバイナリパッケージ（最近のバージョン） contains スキーマ、キーバインディング、およびドキュメント。 -commonパッケージの1つの利点は、通常、ネイティブマシンコードが含まれていないため、同じパッケージファイルがすべてのアーキテクチャに適用されることです。 （厳密に言えば、これは ファイルを/usr/share に配置するための1つの重要な要件です。）

13
Eliah Kagan

次の材料を服用してください：

  • 玉ねぎ
  • トマト
  • パン
  • オリーブ

これらから一品だけ作れますか？いいえ。最終的に何を食べるかは、レシピによって異なります。

各パッケージにはレシピが含まれています。これは、要求された料理を作成するために、食材をどうするかをコンピューターに伝えます。

一部のパッケージでは、成分のリストを共有するのが妥当であり、正常です。もちろん、このコンテキストでは、上記のパッケージが同じプロジェクトからのものである場合にのみ実際に当てはまると予想されます。

2
Lightness Races in Orbit