WrapDBへの新規プロジェクト追加
動作原理
新しいラップは、動作するサブプロジェクトとしてwrapdbリポジトリに提出する必要があります。
WrapDBには、通常のラップとMesonビルド定義パッチ付きのラップの2つのタイプがあります。
Mesonビルド定義パッチ付きのラップは、Debianとほぼ同じように動作します。変更されていない上流のソースパッケージを取得し、パッチとして新しいビルドシステムを追加します。これらのビルドシステムは、subprojects/packagefiles/のサブディレクトリとして保存されます。ビルド定義ファイルのみが含まれています。上流ソースに対するオーバーレイと考えることもできます。
Mesonビルド定義パッチのないラップには、プロジェクトの取得方法を記述するラップメタデータのみが含まれています。
新しいリリースがwrapdbにプッシュされるたびに、バージョン番号が増加した新しいタグが生成され、wrapdb APIリストに新しいリリースが追加されます。古いリリースはすべて変更されません。新しいコミットは常にGitHubのマージリクエストを通じて行われ、提出者以外の誰かによってレビューされる必要があります。
ソースリリースのサブディレクトリは、ラップを含むGitリポジトリに含めないでください。それはサービスによって自動的に追加されます。元のtarballからのソースコードもラップリポジトリにコミットしないでください。
ラップ名の選択
ラップされたサブプロジェクトは、外部依存関係とほぼ同じように使用されます。したがって、上流プロジェクトと同じ名前にする必要があります。
注意：ラップ名は、正規表現[a-z0-9._]+に完全に一致する必要があります。
プロジェクトがpkg-configファイルを提供する場合、ラップ名はpkg-config名と同じにする必要があります。通常はプロジェクト名と同じです（例：libpng）。ただし、場合によっては少し異なる場合があります。例として、liboggプロジェクトのpkg-config名はliboggではなくoggであるため、ラップ名は単純にoggになります。
pkg-configファイルがない場合は、プロジェクトで使用/推奨されている名前（小文字のみ）を使用してください（Catch2 -> catch2）。
プロジェクト名が一般的すぎるか曖昧な場合（例：benchmark）、organization-projectという命名形式を使用することを検討してください（例：google-benchmark）。
新しいラップの寄与方法
プロジェクトがすでにMesonビルドシステムを使用している場合は、project.wrapファイルのみを提供する必要があります。そうでない場合は、Mesonビルド定義パッチ（meson.buildファイルのセット）も提供する必要があります。
ラップの内容の作成
新しいリリースブランチにはproject.wrapファイルが必要です。必要に応じて作成してください。
${EDITOR} upstream.wrap
ファイル形式はシンプルです。既存のwrapdbサブプロジェクトのコンテンツを参照してください。チェックサムはSHA-256であり、ほとんどのUnix系オペレーティングシステムでは次のコマンドで計算できます。
sha256sum path/to/libfoo-1.0.0.tar.gz
macOSでは、コマンドは次のとおりです。
shasum -a 256 path/to/libfoo-1.0.0.tar.gz
次に、現在のプロジェクトが提供する依存関係を定義するエントリを追加する必要があります。これは、Mesonの自動依存関係解決機能が動作する上で重要です。これは、upstream.wrapファイルの最後にprovideエントリを追加することで行われます。Oggライブラリを例として使用すると、次のようになります。
[provide]
ogg = ogg_dep
左側のoggは依存関係名を参照しており、Pkg-Config名と同じにする必要があります。右側のogg_depは、依存関係を提供するビルド定義内の変数を指します。最も一般的には、declare_dependency呼び出しの結果を保持します。その名前の変数が定義されていない場合、Mesonはハードエラーで終了します。詳細については、メインのWrapマニュアルを参照してください。
上流プロジェクトにビルドファイルが含まれていない場合は、ビルドファイルを作成し、プロジェクトが正しくビルドされるまで作業できます。すべてのファイルはsubprojects/packagefiles/ディレクトリに配置されることに注意してください。
${EDITOR} meson.build meson.options
ローカルに追加されたビルドファイルを上流リリースのtarballに適用するには、wrap-fileセクションに、subprojects/packagefiles/内のビルドファイルを含むサブディレクトリ名を指定するpatch_directoryプロパティを含める必要があります。これはwrapdbの動作の中心です。wrapdb meson.buildで使用され、リリースが作成されると、このディレクトリのファイルはアーカイブに変換され、patch_urlがwrapファイルに追加されます。
結果に満足したら、ビルドファイルをGitに追加し、README.mdに記載されているようにreleases.jsonを更新し、結果をGitHubにプッシュします。
<verify that your project builds and runs>
git add releases.json subprojects/project.wrap subprojects/packagefiles/project/
git commit -a -m 'Add wrap files for libfoo-1.0.0'
git push -u origin libfoo
次に、GitHubでプルリクエストを作成する必要があります。
パッケージングレビューで変更が必要な場合は、commitに--amend引数を使用して、ブランチにコミットが1つだけになるようにします。
${EDITOR} meson.build
git commit -u --amend
git push --force
元のソースへの変更
ラップの目的は、上流プロジェクトへの変更をできるだけ少なくすることです。ほとんどのプロジェクトには、いくつかのMeson定義ファイル以上のものを含めるべきではありません。テンプレートヘッダーファイルなどを追加する必要がある場合があります。これらは最小限に抑える必要があります。
特に、機能に対するパッチがあってはならないことに注意してください。そのような変更はすべて上流に提出する必要があります。必要に応じて、変更を含む独自のGitリポジトリをホストすることもできます。Wrapシステムは、Gitサブプロジェクトをネイティブにサポートしています。
自動検証の通過
提出されたすべてのラップは、自動化された正確性レビューを受け、合格することがマージの条件となります。したがって、問題をより迅速に修正できるように、自分で検証チェックを実行することを強くお勧めします。
次のコマンドを使用して、ラップ自体をテストできます。
meson subprojects purge --confirm
meson setup builddir/ -Dwraps=<project-name>
最初のコマンドは、ラップが最新のpackagefilesから正しく取得されていることを確認するためです。2番目のコマンドはmesonを設定し、有効にするサブプロジェクトのセットを選択します。
GitHubプロジェクトには、プロジェクトを実行し、明らかな間違いについてメタデータをチェックするためのプッシュ時の自動CIが含まれています。PRを送信する前に、フォークから確認できます。
検索結果は以下のとおりです。