「Haiku」の移植環境「HaikuPorts」を学び直してみた（その 1）〈H145-8〉

登録日: 2022-02-16 更新日: 2022-03-08

Haiku にて、Linux アプリをHaiku に移植するときに使われる環境「Haikuports」を構築しました。

現在は、Haiku に「mousepad」を移植できないか、ぼちぼちとトライしています。サイトを巡るとHaiku のドキュメント類は豊富だと思いますが、重要な情報は散らばっているし英語です。

移植環境「HaikuPorts」を学び直すこともですが、個人的に使いやすいように備忘録（メモ）として残しました。

記録して残すと勘違いしていた部分に気づいた時にその都度修正でき、資料としての品質が向上して行きます。ただし、散らばっている情報を集めたので、かなりの重複があるようです。

使う時は公式サイトにある本来の英語版が確実です。

実際にHaiku に移植環境を構築するときは、動いた実績のある「こちら」を参照するとよいです。

追記:

haikuports/haikuports Home の右サイトに、こちらで紹介した有益な情報のリンクの一覧がありました。気づきませんでした。本来の英語版はこのリンクから確認すると良いです。

VirtualBox に「nightly ビルド」の「Haiku R1/beta3」をインストールしました。システムとしては最新です。そこで作業しました。

使用したPC は「ASUS Chromebox CN60」で、プロセッサは第4世代の「Intel Celeron 2955U 」です。

（注）リンクを戻るときはブラウザの左上の「←」をクリック

--- - --- - --- - --- - --- - --- - --- - --- - --- - --- - --- - -

「 Haiku R1/beta3」のデスクトップ

「nightly ビルド」のデスクトップ画面:

→「nightly ビルド」は開発版と言えますが、更新の回数が多いので不具合が解消されている可能性があります。

「nightly ビルド」のアイコン:

→立ち上げデバイス（ボリューム）には「てんとう虫」マークが付きます。

--- - --- - --- - --- - --- - --- - --- - --- - --- - --- - --- - --

現在のシステムのバージョン:

2022-02-14 現在:

~> uname -v
hrev55874 Feb  14 2022 09:04:41

→「nightly ビルド」は、頻繁に更新されています。

--- - --- - --- - --- - --- - --- - --- - --- - --- - --- - --- - ---

1. インストールした「haikuporter」に添付の README.md を参照してみる:

> cat ~/Git/haikuporter/README.md

和訳:

Haikuporter ツール

HaikuPorter ツールは、ソースコードの読み込み、パッチの適用、およびビルドを容易にするために提供されました。 Gentoo Portage を簡素化したみたいなものです。

各ポート（プロジェクト、パッケージ）には、元のソースコードに対するHaiku 固有のパッチ（Haiku で使えるようにするための修正）が含まれています。元のソースコードを取得し、そのソースにHaiku 固有のパッチを適用し、ソフトウェアをビルドして、パッケージ化する手順を実行します。

詳細は haikuports/haikuports wiki を参照。

Haiku だけのシステムの場合:

HaikuPorts のインストール:

git clone https://github.com/haikuports/haikuporter.git
git clone https://github.com/haikuports/haikuports.git --depth=10
cd haikuporter
cp haikuports-sample.conf /boot/home/config/settings/haikuports.conf # Copy the config file
lpe ~/config/settings/haikuports.conf # and edit it

ポートをビルド:

./haikuporter ポート名 -j2

ポートとすべての古い依存関係のポートをビルド

./haikuporter ポート名 --all-dependencies -j2

マルチノードクラスターシステム (Linux + Haiku) の場合:

マルチノードクラスターは、多数のパッケージを大量に構築するためのシステムです。

追記: コンテナのスキルがないので、一部理解していない部分があります。

Docker を使用したコンテナーでbuildmaster を実行:

docker pull haikuporter/buildmaster
mkdir ~/buildmaster.x86
docker run -v ~/buildmaster.x86:/data -it -e ARCH=x86 haikuporter/buildmaster

builders をプロビジョニング

createbuilder -n test01 -H 127.0.0.1
copy generated public key to builder
builderctl health
exit

パッケージをHaiku のnightly からビルドマスターのports/packages にコピーします

docker run -v ~/buildmaster.x86:/data -it -e ARCH=x86 haikuporter/buildmaster
buildmaster everything

buildmaster.x86 は、ビルドの実行の間は保持されます。終了、更新、または作業内容を失うことなくコンテナを消去します。

buildmaster を手動でインストール (Linux):

インストール要件

pip install paramiko または、dnf install python-paramiko
buildtools の依存関係: autoconf、flex、bison、texinfo、zlib-devel
Haiku ホストツールの依存関係: libstdc++-static、libcurl-devel

buildmaster インスタンスをブートストラップします

git clone https://github.com/haikuports/haikuporter.git
./haikuporter/buildmaster/bin/bootstrap_buildmaster.sh ...

createbuilder を使用してインスタンスポートツリー内でビルダーを構成します

cd buildmaster_<arch>/haikuports

例:

../haikuporter/buildmaster/bin/createbuilder -n mybuilder01 -H 127.0.0.1

ビルダーを検証してプロビジョニングします

../haikuporter/buildmaster/bin/builderctl health
../haikuporter/buildmaster/bin/builderctl provision
../haikuporter/buildmaster/bin/buildmaster everything

buildslave をインストールします (Haiku)

Buildmaster 側のcreatebuilder で指定されたパスに一致するHaikuporter とHaikuports をチェックアウトします
buildmaster からauthorized_keys に公開鍵を追加します
useradd sshd ; ssh-keygen -A
/system/settings/ssh/sshd_config でPermitRootLogin を有効にし、sftp サーバーへのパスが正しいことを確認します
xz_utils_x86, lzip_x86（パッケージの抽出に必要）、patch、dos2unix（一部のパッケージのPATCH() 関数に必要）をインストールします

haikuporter の設定ファイルのサンプルを確認:

> cd ~/Git/haikuporter/
> cat haikuports-sample.conf

# Example HaikuPorts configuration
#
# =============
# Installation:                                                       ←（自分のPC の場合の操作）
#   1) cp haikuports-sample.conf ~/config/settings/haikuports.conf
#
#   2) customize your settings:
#      lpe ~/config/settings/haikuports.conf

# ==================
# Tip:
#
# Put this into your ~/config/settings/profile to search for a string in all
# recipes with "inrecipe {searchstring}" and build a package with
# "hp {packagename}" (adjust your /path/to/your/haikuports/):
#
#       function inpatch () { grep -rni $1 /path/to/your/haikuports/*/*/patches/*; }
#       function inrecipe { find /path/to/your/haikuports -maxdepth 3 \
#            -name "*.recipe" | xargs grep -ni --col $1; }
#
#       alias hp="haikuporter -S -j8 --no-source-packages --get-dependencies"
# alias hp="haikuporter -S -j2 --no-source-packages --get-dependencies"     ←（自分のPC の場合の操作）

# ==================
# Required settings:
#

# --------------
# TREE_PATH:
#     The full path to your cloned haikuports tree.
#TREE_PATH="/boot/home/haikuports"
TREE_PATH="/boot/home/Git/haikuports"     ←（自分のPC の場合）

# --------------
# PACKAGER:
#     Your name and email
#PACKAGER="My Name <mymail@mydomain.org>"
PACKAGER="FuRuYa7 <mymail@mydomain.org>"     ←（自分のPC の場合）

# ==================
# Optional settings:

# --------------
# VENDOR:
#     Sets a custom VENDOR tag that will be inserted into all built packages
#     ("Haiku Project" by default).
#VENDOR="Haiku Project"

# --------------
# ALLOW_UNTESTED:
#     Allow build of untested recipes. '?x86' for example
#ALLOW_UNTESTED="yes"

# --------------
# ALLOW_UNSAFE_SOURCES:
#     Allow building from unsafe sources. Setting this to yes allows
#     downloading sources for which there is no possibility to check if they
#     have been corrupted or tampered with.
#
#     Only set this to yes if you really need this and know what you're doing,
#     for example if you want to build recipes for development versions that
#     fetch the head from a repository.
#ALLOW_UNSAFE_SOURCES="yes"

# --------------
# TARGET_ARCHITECTURE:
#     The primary architectures you wish to compile recipes for.
#     Defaults to the current primary platform.
#TARGET_ARCHITECTURE="x86_gcc2"

# --------------
# SECONDARY_TARGET_ARCHITECTURES:
#     Secondary platforms you wish to build packages for (one per line)
#     Example is x86 (gcc4) packages on a x86_gcc2 (gcc2) system
#     Default is no secondary target architectures.
#SECONDARY_TARGET_ARCHITECTURES="x86"

→こちらのコピーを配置して、修正して使います。

ports ツリー（パッケージのカテゴリ分け）を確認:

> cd ~/Git/haikuports/
> ls -a
.                  dev-dotnet       games-roguelike      net-dialup       sci-libs
..                 dev-embedded     games-rpg            net-dns          sci-mathematics
.git               dev-games        games-simulation     net-firewall     sci-physics
.gitattributes     dev-go           games-sports         net-fs           sci-visualization
.gitignore         dev-haskell      games-strategy       net-ftp          sys-apps
.travis.yml        dev-java         games-util           net-im           sys-auth
app-accessibility  dev-lang         gnome-base           net-irc          sys-block
app-admin          dev-libs         gnome-extra          net-libs         sys-boot
app-arch           dev-lisp         haiku-apps           net-mail         sys-cluster
app-backup         dev-lua          haiku-data           net-misc         sys-devel
app-benchmarks     dev-perl         haiku-games          net-nds          sys-firmware
app-cdr            dev-python       haiku-libs           net-news         sys-fs
app-crypt          dev-qt           haiku-misc           net-nntp         sys-libs
app-dicts          dev-rust         kde-apps             net-p2p          sys-power
app-doc            dev-scheme       kde-base             net-print        sys-process
app-editors        dev-tcltk        kde-frameworks       net-proxy        www-aps
app-emulation      dev-util         kde-misc             net-voip         www-client
app-forensics      dev-vcs          LICENSE.md           net-vpn          www-misc
app-i18n           FormatVersions   lint-new-recipes.sh  net-wireless     www-servers
app-misc           games-action     lxde-base            net-www          x11-base
app-mobilephone    games-arcade     mail-client          packages         x11-doc
app-office         games-board      media-fonts          README.md        x11-libs
app-pda            games-emulation  media-gfx            repository       x11-misc
app-shells         games-engines    media-libs           sci-astronomy    x11-proto
app-text           games-fps        media-plugins        sci-biology      x11-themes
app-vim            games-kids       media-sound          sci-calculators
CONTRIBUTING.md    games-misc       media-video          sci-chemistry
dev-cpp            games-mud        meta-ports           sci-electronics
dev-db             games-puzzle     net-analyzer         sci-geosciences

→Gentoo Linux に習ったフォルダ分けです。後はgit 関連、LICENSE.md、README.md

git の定義でコミットの管理から外してあるファイルを確認:

> cd ~/Git/haikuports/
> cat .gitignore
/haikuports.conf
/buildmaster
/packages
/repository
/repository-*
/*/*/download
/*/*/work-*

→ここでの「/」は「.git」のある位置です。当然ながら、各ポートのダウンロードフォルダ「/*/*/download」と作業フォルダ「/*/*/work-*」、および生成されたパッケージが入るフォルダ「/packages」は外されていて、git log では更新履歴は確認できません。

ちなみに、パッケージ化を実行すると、自動でそのポートの作業フォルダ「/*/*/work-*」にできるsources 配下にも「.git」が作成され、ポートの更新履歴は別で管理されます。

README.md を確認:

> cat README.md
# Welcome to HaikuPorts!

To get started, [read the wiki!](https://github.com/haikuports/haikuports/wiki/)

→HaikuPorts の使用を開始するには、 wiki を参照。

--- - --- - --- - --- - --- - --- - --- - --- - --- - --- - --- - ----

2.「haikuports/haikuports wiki」を参照してみる:

参考:

haikuports/haikuports wiki

HaikuPorts へようこそ！

HaikuPorts は、Haiku に移植されたソフトウェアを集めたコレクションです。 POSIX との互換性の向上など、Haiku には、BeOS やZeta に比べて多くのAPI での利点があります。このサイトの主な目的は、移植作業に協力することです。

HaikuPorter

1). HaikuPorts のインストール:

> git clone https://github.com/haikuports/haikuporter.git --depth=50
> git clone https://github.com/haikuports/haikuports.git --depth=50

> cd haikuporter
> cp haikuports-sample.conf /boot/home/config/settings/haikuports.conf # 構成ファイルをコピーします
> lpe ~/config/settings/haikuports.conf # 編集します

→「--depth=50」の値のままだとディスク容量も時間もかかるので、さらに小さくしてもOK。その分過去の履歴が使えないだけです。

2). haikuports.conf ファイルで、PACKAGER 変数を「自分の名前/メール」に設定します

TREE_PATH をhaikuports リポジトリのクローンを作成した場所に設定します

haikuports.conf ファイルの変数の詳細は、こちらを参照。

3). HaikuPorter ツールをどこからでも実行できるように設定:

→クーロンを作成した場所に、haikuporter をシンボリックリンクします。

このガイドの場合は「/boot/home/」に配置:

> ln -s /boot/home/haikuporter/haikuporter /boot/home/config/non-packaged/bin/

自分のPC の場合は「/boot/home/Git/」に配置:

> ln -s /boot/home/Git/haikuporter/haikuporter /boot/home/config/non-packaged/bin/
> ls -l /boot/home/config/non-packaged/bin/
:
lrwxrwxrwx 1 user root 38  2月  7 09:04 haikuporter -> /boot/home/Git/haikuporter/haikuporter

4). さらに使いやすくするためのツールを準備:

下記を ~/config/settings/profile に（haikuports/ のパスを調整して）入力すると、「inpatch {searchstring}」でパッチにある文字列を検索、「inrecipe {searchstring}」でレシピにある文字列を検索、hp {packagename}でパッケージをビルド、できます。

ちなみに、「-j8」は、コンパイル時に使うCPU コアの数（パソコンで最大値は異なります）です。

「profile」ファイルがまだ存在しない場合は、作成します:

このガイドの場合（ /boot/home/）:

function inpatches() { grep -rni $1 /boot/home/haikuports/*/*/patches/*; }
function inrecipe { find /boot/home/haikuports -maxdepth 3 -name "*.recipe" \
| xargs grep -ni --col $1; }

#alias hp="haikuporter -S -j8 --no-source-packages --get-dependencies"

→CPU コア: 8 の場合で、「~/」にポートツリーを作成

自分のPC の場合（ /boot/home/Git/）:

function inpatches() { grep -rni $1 /boot/home/Git/haikuports/*/*/patches/*; }
function inrecipe { find /boot/home/Git/haikuports -maxdepth 3 -name "*.recipe" \
| xargs grep -ni --col $1; }
alias hp="haikuporter -S -j2 --no-source-packages --get-dependencies"

→CPU コア: 2 の場合で、「~/Git/」にポートツリーを作成

→追記: （参考: 個人的に使いやすいように修正）

参考: より上級のユーザの場合は、HaikuPorts が従うポリシーにも注意

→Haiku では推奨されていないポートがあるようです。

--- - --- - --- - --- - --- - --- - --- - --- - --- - --- - --- - -----

3. 初心者向けの、「HaikuPorter の大まかな紹介（パート1）」を参照してみる:

参考:

A Gentle Introduction to HaikuPorter #1

HaikuPorter の使い方とレシピの書き方を学びます。プログラム言語の深い知識は必要ありません。

「haikuporter」は、Haiku の一般的なパッケージをビルドするためのツールです。それらのパッケージのベースとしてhaikuports リポジトリを使います。

パッケージには対応する「レシピファイル」があり、ソースを取得する場所、適用するパッチ、プロジェクトの構成、ビルド、およびインストールの方法を「haikuporter」に指示します。

レシピファイルを配布することで、他の人が同じパッケージを作成できます。

つまり、haikuporter は、配布用のHaiku の .hpkg パッケージを作成する準備をします。

1). Haiku のnightly イメージを使用している場合は、最新のリビジョンにアップグレードします

2). 「haikuporter」と「haikuports」をインストール:

git を介してソースを取得:

「はじめに」(Get Started section) を参照

3). haikuports のソースツリーの場所を設定:

haikuports のソースツリーの場所を「$TREE_PATH」と呼びます。

「$TREE_PATH」は、haikuports.conf ファイルで定義されます

これは、BuildRecipes wiki ページで説明されています

「$TREE_PATH」内には、Gentoo に従ってカテゴリ分けされたパッケージ群が置かれています。

--- - --- - --- - --- - --- - --- - --- - --- - --- - --- - --- - ----- -

4. Haiku のports に新しいポートを追加するとき

新しいポートを追加するときは、「https://packages.gentoo.org/」の階層を参照:

→Gentoo のカテゴリ分けに従います

従うことで、適切にプロジェクト（パッケージ）のカテゴリ分けが出来る、迷わない、うまいやり方です。

もし、gentoo のパッケージが存在しない場合は、合理的で論理的なカテゴリ分けにします

例: 「gtksourceview」パッケージのカテゴリ名を調べる:

gentoo Linux でパッケージ検索

「gtksourceview」を入力

→表示された一覧から、下記を選択:

x11-libs/gtksourceview :

カテゴリ名:
x11-libs

パッケージ名:
gtksourceview

概要:
A text widget implementing syntax highlighting and other features

ホームページ:
https://wiki.gnome.org/Projects/GtkSourceView

ヒント:
バージョン5.2.0 はアップストリームで利用できます。更新を検討してください！
バージョン5.2.0 はアップストリームで利用できるようですが、
Gentoo ツリーの最新バージョンは4.8.2 です。

利用可能なバージョン:
4.8.2 : 4
3.24.11 : 3.0
2.10.5-r3 : 2.0

→レシピファイル作成の参考になりそうな情報を入手できます。

「Available Versions」にある一覧の「Version」のバージョン番号「4.8.2」をクリック

index : repo/gentoo.git

path: root/x11-libs/gtksourceview/gtksourceview-4.8.2.ebuild
blob: 303e382be3906d0e0254db348a3630344afe8df5 (plain)

# Copyright 1999-2021 Gentoo Authors
# Distributed under the terms of the GNU General Public License v2

EAPI=7

inherit gnome.org meson vala virtualx xdg

DESCRIPTION="A text widget implementing syntax highlighting and other features"
HOMEPAGE="https://wiki.gnome.org/Projects/GtkSourceView"

LICENSE="LGPL-2.1+"
SLOT="4"

IUSE="glade gtk-doc +introspection +vala"
REQUIRED_USE="vala? ( introspection )"

KEYWORDS="~alpha amd64 arm arm64 ~ia64 ~mips ppc ppc64 ~riscv sparc x86 ~amd64-linux ~x86-linux ~ppc-macos ~x86-solaris"

RDEPEND="
    >=dev-libs/glib-2.48:2
    >=x11-libs/gtk+-3.24:3[introspection?]
    >=dev-libs/libxml2-2.6:2
    glade? ( >=dev-util/glade-3.9:3.10 )
    introspection? ( >=dev-libs/gobject-introspection-1.42.0:= )
    >=dev-libs/fribidi-0.19.7
"
DEPEND="${RDEPEND}"
BDEPEND="
    dev-util/glib-utils
    gtk-doc? (
        >=dev-util/gtk-doc-1.25
        app-text/docbook-xml-dtd:4.3
    )
    >=sys-devel/gettext-0.19.8
    virtual/pkgconfig
    vala? ( $(vala_depend) )
"

src_prepare() {
    use vala && vala_src_prepare
    xdg_src_prepare
}

src_configure() {
    local emesonargs=(
        $(meson_use glade glade_catalog)
        -Dinstall_tests=false
        $(meson_use introspection gir)
        $(meson_use vala vapi)
        $(meson_use gtk-doc gtk_doc)
    )
    meson_src_configure
}

src_test() {
    virtx meson_src_test
}

src_install() {
    meson_src_install

    insinto /usr/share/${PN}-4/language-specs
    newins "${FILESDIR}"/4.6-gentoo.lang gentoo.lang

    # Avoid conflict with gtksourceview:3.0 glade-catalog
    # TODO: glade doesn't actually show multiple GtkSourceView widget collections, so with both installed, can't really be sure which ones are used
    if use glade; then
        mv "${ED}"/usr/share/glade/catalogs/gtksourceview.xml "${ED}"/usr/share/glade/catalogs/gtksourceview-${SLOT}.xml || die
    fi
}

→こんなに違うと、Haiku のレシピファイルを作るときの参考にできるのは頭の部分くらい。

依存の指定の仕方はパッケージ名がはっきりと決まっているgentoo の方が融通は効かないけどわかりやすいかも。Haiku だと頭にlib を付けたり付けなかったり、試行錯誤が必要。←この辺りの情報は下記。

HaikuPorter HandlingRequirements を参照すると、依存の指定の仕方の記述がありました。

lib を付けたり付けなかったりするパッケージ名の部分は「ライブラリベース名」でした。

 lib:libgtk_3$secondaryArchSuffix
    lib:libxml_2.0$secondaryArchSuffix
    lib:libfribidi$secondaryArchSuffix

→パッケージによって、「ライブラリベース名」の付け方は変わるので、混乱（自分だけ？）します。

ライブラリならlib を付けるのが普通だけど、付けないパッケージもあるし、パッケージ名にメインバージョンも含めたり、含めなかったり、数字の含め方も違います。

→例えば、「libgtk_3」なのは、それはパッケージ名だからということ。バージョン番号なら「-」区切り。

ここで、「dependencies」タブをクリックすると、「依存」が表示:

→「依存」の情報は重要です。

gtksourceview 4.8.2

Version	RDEPEND	DEPEND	BDEPEND	PDEPEND
app-arch/xz-utils	-	-	✅	-
app-text/docbook-xml-dtd	-	-	✅	-
dev-lang/vala	-	-	✅	-
dev-libs/fribidi	✅	✅	-	-
dev-libs/glib	✅	✅	-	-
dev-libs/gobject-introspection	✅	✅	-	-
dev-libs/libxml2	✅	✅	-	-
dev-util/desktop-file-utils	-	✅	-	-
dev-util/glade	✅	✅	-	-
dev-util/glib-utils	-	-	✅	-
dev-util/gtk-doc	-	-	✅	-
dev-util/meson	-	-	✅	-
dev-util/meson-format-array	-	-	✅	-
dev-util/ninja	-	-	✅	-
sys-devel/gettext	-	-	✅	-
virtual/pkgconfig	-	-	✅	-
x11-apps/xhost	-	-	✅	-
x11-base/xorg-server	-	-	✅	-
x11-libs/gtk+	✅	✅	-	-
x11-misc/shared-mime-info	-	✅	-	-

RDEPEND: 実行時に必要な依存

DEPEND: RDEPEND にはあるが、DEPEND にはないアイテムは、後でマージできます

BDEPEND: ビルド時に必要な依存

PDEPEND: すぐに満たされる必要のない実行時の依存。通常は代わりにRDEPENDを使用

--- - --- - --- - --- - --- - --- - --- - --- - --- - --- - --- - ----- --

5. 初心者向けの、「HaikuPorter の大まかな紹介（パート2）」を参照してみる:

参考:

A Gentle Introduction to HaikuPorter #2

「A Gentle Introduction to HaikuPorter #1」に記述されていた「素のレシピ」:

SUMMARY="ProjectX"
DESCRIPTION="ProjectX description."
HOMEPAGE="http://projectX"
COPYRIGHT="<copyright notice>"
LICENSE="GNU GPL v2"
REVISION="1"
SOURCE_URI="git://projectX/projectX.git"
#PATCHES=""

ARCHITECTURES="x86 x86_gcc2"

PROVIDES="
    projectX = $portVersion
    "
REQUIRES="
        haiku
        "

BUILD_REQUIRES="
        haiku_devel
        "

BUILD()
{
    ./autogen.sh
    runConfigure ./configure
    make $jobArgs
}

INSTALL()
{
    make install
}

上記を参考に、「which」の場合を確認しながら学習して行く説明です。

→ビルドしてパッケージ化することで、そのレシピを他のHaiku システムで使え、同じパッケージを再ビルドできます。

ここでは、「sed-4.4.recipe」のパッケージのレシピを確認しながら学習しました:

→「sed」の場合、3つのバージョンのレシピが登録されているので、勉強になります。

例: 「sed」パッケージのカテゴリ名を調べる:

gentoo Linux でパッケージ検索

「sed」を入力

→表示された一覧から、下記を選択:

sys-apps/sed :

カテゴリ名:
sys-apps

パッケージ名:
sed

概要:
Super-useful stream editor

ホームページ:
http://sed.sourceforge.net/

License:
GPL-3

利用可能なバージョン:
4.8 : 0

「Available Versions」にある一覧の「Version」のバージョン番号「4.8」をクリック

→「.ebuild」ファイルを確認できました:

index : repo/gentoo.git (Official Gentoo ebuild repository) のページが表示:

https://gitweb.gentoo.org/repo/gentoo.git/tree/sys-apps/sed/sed-4.8.ebuild

「tree」タブ:

path: root/sys-apps/sed/sed-4.8.ebuild
blob: 69f4960ab94f72caa6ada70bd536617c5b972d28 (plain)

# Copyright 1999-2022 Gentoo Authors
# Distributed under the terms of the GNU General Public License v2

EAPI=7

inherit flag-o-matic

DESCRIPTION="Super-useful stream editor"
HOMEPAGE="http://sed.sourceforge.net/"
SRC_URI="mirror://gnu/sed/${P}.tar.xz"

LICENSE="GPL-3"
SLOT="0"
KEYWORDS="~alpha amd64 arm arm64 hppa ~ia64 ~m68k ~mips ppc ppc64 ~riscv ~s390 sparc x86"
IUSE="acl nls selinux static"

RDEPEND="
    !static? (
        acl? ( virtual/acl )
        nls? ( virtual/libintl )
        selinux? ( sys-libs/libselinux )
    )
"
DEPEND="${RDEPEND}
    static? (
        acl? ( virtual/acl[static-libs(+)] )
        nls? ( virtual/libintl[static-libs(+)] )
        selinux? ( sys-libs/libselinux[static-libs(+)] )
    )
"
BDEPEND="nls? ( sys-devel/gettext )"

src_configure() {
    use static && append-ldflags -static

    local myconf=(
        --exec-prefix="${EPREFIX}"
        $(use_enable acl)
        $(use_enable nls)
        $(use_with selinux)
    )
    econf "${myconf[@]}"
}

Haiku に存在するパッケージかを確認:

> which sed
/bin/sed

ポートツリーの位置を確認:

> haikuporter -o sed
/boot/home/Git/haikuports/sys-apps/sed

> ls -1 /boot/home/Git/haikuports/sys-apps/sed
patches
sed-4.2.1.recipe
sed-4.4.recipe
sed-4.8.recipe
work-4.8

> ls -1 /boot/home/Git/haikuports/sys-apps/sed/patches/
sed-4.2.1.patchset
sed-4.4.patchset
sed-4.8.patchset

→バージョンが上がればレシピやパッチは上書きされて、1つのファイルになっているのが普通ですが、時々、複数（ここでは 3つ）のバージョンのレシピとパッチが置かれているときがあります。

> ls -1 /boot/home/Git/haikuports/sys-apps/sed/work-4.8/
port.recipe

→デフォルトで作成される作業フォルダは一番上のバージョンです。 port.recipe は選ばれたレシピファイル（ここでは、sed-4.8.recipe）と同じ内容です。

参考: ちなみに、サイトでも確認できます:

Github haikuports/haikuports

画面左上で「sed」で検索

sys-apps/sed/sed-4.2.1.recipe
sys-apps/sed/sed-4.4.recipe
sys-apps/sed/sed-4.8.recipe

→勉強のため、真ん中のバージョンの「sed-4.4.recipe」を選びました:

haikuports/sys-apps/sed/sed-4.4.recipe

レシピを記述する手順：

1). ソースファイルについて知ります： .tgz へのURL？または git リポジトリ？ 2). 基本となるレシピを作成 3). レシピを更新 4). レシピをビルド 5). パッケージ化

1). ソースファイルについて調べます:

Haikuporter はさまざまなソースを使用してパッケージのソースコードをダウンロードできます。

(1). tar.gz やtar.bz2 などのアーカイブファイルの場合の指定:

SOURCE_URI="https://ftpmirror.gnu.org/sed/sed-$portVersion.tar.xz
    https://ftp.gnu.org/gnu/sed/sed-$portVersion.tar.xz"

→ひとつでも複数でも指定できるみたい。ダウンロードするファイルの内容は同じです。

(2). 特定のコミットハッシュタグを含む Git リポジトリの場合の指定:

SOURCE_URI="git://github.com/cherokee/webserver.git#4119ec4e1b6ad29f0115c462d11ac20e36975f53"
    # 24 Oct 2013 commit.

(3). サポートされているオプションは、「BuildRecipes」ページを確認

http://、https://、ftp://、bzr:、cvs:、fossil:、hg:、svn:、などのURI のサポートが含まれています。

2). 基本となるレシピを作成

$TREE_PATH 内の適切な場所に新しいレシピファイルを作成する必要があります。

→ファイルされる場所の説明は、「Welcome to the Home of 19,481 Gentoo Packages 」を参照

(1). 例えば、「sed」を検索すると、/sys-apps/ にあることがわかります:

> haikuporter -o sed
/boot/home/Git/haikuports/sys-apps/sed

> cd /boot/home/Git/haikuports/sys-apps/sed/
~/Git/haikuports/sys-apps/which> ls *.recipe
sed-4.2.1.recipe sed-4.4.recipe sed-4.8.recipe

(2). 学習に使うので、まずは、オリジナルを退避しました:

> cd ~/Git/haikuports/sys-apps/which/
> cp sed-4.4.recipe sed-4.4.recipe-ORG
> ls *recipe*
sed-4.2.1.sed-4.4.recipe sed-4.4.recipe-ORG sed-4.8.recipe

(3). これで、気兼ねなく目的のファイル「sed-4.4.recipe」を編集できます:

> cd ~/Git/haikuports/sys-apps/sed/
> lpe sed-4.4.recipe

SUMMARY="The famous stream editor"
DESCRIPTION="Sed is a stream editor, i.e. it can be used to perform basic \
text transformations on an input stream (a file or input from a pipeline).
While in some ways similar to an editor which permits scripted edits (such as \
ed), sed works by making only one pass over the input(s), and is consequently \
more efficient. But it is sed's ability to filter text in a pipeline which \
particularly distinguishes it from other types of editors."
HOMEPAGE="https://www.gnu.org/software/sed/"
COPYRIGHT="1989-2017 Free Software Foundation, Inc."
LICENSE="GNU GPL v3"
REVISION="3"
SOURCE_URI="https://ftpmirror.gnu.org/sed/sed-$portVersion.tar.xz
    https://ftp.gnu.org/gnu/sed/sed-$portVersion.tar.xz"
CHECKSUM_SHA256="cbd6ebc5aaf080ed60d0162d7f6aeae58211a1ee9ba9bb25623daa6cd942683b"
PATCHES="sed-$portVersion.patchset"

ARCHITECTURES="all !x86_gcc2 ?arm"
if [ "$targetArchitecture" = x86_gcc2 ]; then
SECONDARY_ARCHITECTURES="x86"
fi

commandBinDir=$binDir
if [ "$targetArchitecture" = x86_gcc2 ]; then
    commandBinDir=$prefix/bin
fi

PROVIDES="
    sed$secondaryArchSuffix = $portVersion compat >= 4
    cmd:sed = $portVersion compat >= 4
    "
REQUIRES="
    haiku$secondaryArchSuffix
    "
if [ -n "$secondaryArchSuffix" ]; then
CONFLICTS="
    sed
    "
fi

BUILD_REQUIRES="
    haiku${secondaryArchSuffix}_devel
    "
BUILD_PREREQUIRES="
    cmd:awk
    cmd:g++$secondaryArchSuffix
    cmd:grep
    cmd:ld$secondaryArchSuffix
    cmd:make
    "

TEST_REQUIRES="
    cmd:cmp
    "

defineDebugInfoPackage sed$secondaryArchSuffix \
    "$commandBinDir"/sed


BUILD()
{
    runConfigure --omit-dirs binDir ./configure --bindir="$commandBinDir" \
        --enable-regex-tests --without-included-regex \
        --disable-rpath --with-gnu-ld
    make $jobArgs
}

INSTALL()
{
    make install
    rm "$libDir"/charset.alias
    rmdir "$libDir"
}

TEST()
{
    make check
}

3). レシピを更新

ここで、レシピを作成しながら、各セクションとその値を確認して行きます。

(1). 「SUMMARY=」（要約）は、パッケージの簡単な概要を提供します。最大長は70文字です

SUMMARY="The famous stream editor"

→行末に「.」は使えません。

70文字以下である必要があります。 70文字を超えると、Haikuporter は警告を表示します。

「SUMMARY=」が定義されていない場合はビルドに失敗します。

(2). 「DESCRIPTION=」（説明）は、パッケージのより長い概要を提供します

DESCRIPTION="Sed is a stream editor, i.e. it can be used to perform basic \
text transformations on an input stream (a file or input from a pipeline).
While in some ways similar to an editor which permits scripted edits (such as \
ed), sed works by making only one pass over the input(s), and is consequently \
more efficient. But it is sed's ability to filter text in a pipeline which \
particularly distinguishes it from other types of editors."

→複数の行にまたがることができます。「 \」で改行すると、表示は改行されるけど、実際には改行されない文章にできます。

(3). 「HOMEPAGE=」は、パッケージの公式 Web サイトへのURL です

HOMEPAGE="https://www.gnu.org/software/sed/"

(4). 「COPYRIGHT=」は、パッケージに関連付けられている所有権と著作権情報を記述します

COPYRIGHT="1989-2017 Free Software Foundation, Inc."

(5). 「LICENSE=」は、パッケージで使用される特定のライセンスモデルを定義します。これは有効な定義である必要があります

LICENSE="GNU GPL v3"

→使える候補は決まっており、候補にない文字列だとエラーとなり、候補の文字列が表示されます。

(6). 「REVISION="3"」に設定されているので、1つ増やします

REVISION="4"

→新規にポートを作成するときは「1」に戻します。

(7). 「SOURCE_URI=」は、「sed-4.4」をダウンロードできる場所を定義します

SOURCE_URI="https://ftpmirror.gnu.org/sed/sed-$portVersion.tar.xz
    https://ftp.gnu.org/gnu/sed/sed-$portVersion.tar.xz"

→ひとつ以上のURL を指定できます。ダウンロードされるファイル内容は同じです。ダウンロードできる確実性が増します。

(8). 「CHECKSUM_SHA256=」は、「SOURCE_URI=」を使用する場合のSHA256 ハッシュです

CHECKSUM_SHA256="cbd6ebc5aaf080ed60d0162d7f6aeae58211a1ee9ba9bb25623daa6cd942683b"

→URL が 2つ記述されていても、同じファイル内容なのでチェックサム値は同じです。

この行が記述されていない場合、HaikuPorter は警告を表示します。ただし、エラー内容として、計算されたチェックサム値が表示されるのでそれを参考に修正できます。

(9). 「ARCHITECTURES=」は、定義されているアーキテクチャです

ARCHITECTURES="all !x86_gcc2 ?arm"
if [ "$targetArchitecture" = x86_gcc2 ]; then
SECONDARY_ARCHITECTURES="x86"
fi

commandBinDir=$binDir
if [ "$targetArchitecture" = x86_gcc2 ]; then
    commandBinDir=$prefix/bin
fi

→珍しく、複雑な定義がされています。

「all !x86_gcc2」は、レシピがx86_gcc2 （は動かないので）除く、すべてのアーキテクチャー用に構築できることを示します。arm はテストされていません。x86_gcc2 の場合は、x86 が使われます。

アーキテクチャによって、コマンドラインの実行ファイルを置く場所を指定しています。

(10). 「PROVIDES=」は、提供される機能を記述します

PROVIDES="
    sed$secondaryArchSuffix = $portVersion compat >= 4
    cmd:sed = $portVersion compat >= 4
    "

パッケージ ''sed'' を提供します（バージョン 4 以降）

コマンド ''sed'' を提供します（バージョン 4 以降）

(11). 「REQUIRES=」は、実行に必要なパッケージを記述します

REQUIRES="
    haiku$secondaryArchSuffix
    "
if [ -n "$secondaryArchSuffix" ]; then
CONFLICTS="
    sed
    "
fi
"

→「haiku」の基本パッケージがインストールされている必要があります。および、条件が付加されています。

(12). 「BUILD_REQUIRES=」は、ビルドに必要なパッケージを記述します

BUILD_REQUIRES="
    haiku${secondaryArchSuffix}_devel
    "

→「haiku」の開発パッケージがインストールされている必要があります。

(13). 「BUILD_PREREQUIRES=」は、ビルドに必要な開発パッケージやコマンドを定義します

BUILD_PREREQUIRES="
    cmd:awk
    cmd:g++$secondaryArchSuffix
    cmd:grep
    cmd:ld$secondaryArchSuffix
    cmd:make
    "

→上記のコマンドが必要です。

(14). 「BUILD_PREREQUIRES=」は、テストに必要なパッケージやコマンドを定義します

BUILD_PREREQUIRES="
    cmd:awk
    cmd:g++$secondaryArchSuffix
    cmd:grep
    cmd:ld$secondaryArchSuffix
    cmd:make
    "

→上記のコマンドが必要です。

(15). 「PATCHES=」は、SOURCE_URI を介してダウンロードされたソースに適用するパッチを定義します

PATCHES="sed-$portVersion.patchset"

→「$TREE_PATH/sys-apps/which/patches/which-2.20.patch」のパッチファイルをよく読んでください。

haikuporter でパッチを作成する方法については後で説明します。これは標準の差分のセットであることに注意。

この記事ではパッチを作成しませんが、すでに提供されているパッチを適用します。

適用するパッチセットがない場合は、定義ブロック全体をコメントアウトします:

#PATCHES="
#   "

(16). 「BUILD()」は、通常、パッケージをビルドする一連の手順を指示します

BUILD()
{
    runConfigure --omit-dirs binDir ./configure --bindir="$commandBinDir" \
        --enable-regex-tests --without-included-regex \
        --disable-rpath --with-gnu-ld
    make $jobArgs
}

以前は、ソースディレクトリを明示的に入力する必要がありましたが、現在は必要ないため、古いレシピ、またはBEPs を変換する場合は、必要に応じて「cd package」コマンドを削除することを忘れないでください。

→ここでは、「runConfigure」と「make」の 2つのコマンドを実行しています。

「runConfigure」は「./configure」を呼び出し、その他の引数を渡します。

「runConfigure」は、Haiku での多くの面倒な作業を行います

→そのため、多くの一般的な「configure」引数にHaiku 固有の場所を指定する必要はありません

次に「make」が呼び出され、「$jobArgs」が渡されます

→「-j2」を指定してhaikuporter を実行した場合、これは「$jobArgs」を介して「make」に渡されます。

(17). 「INSTALL()」は、パッケージをインストールする一連の手順を指示します

INSTALL()
{
    make install
    rm "$libDir"/charset.alias
    rmdir "$libDir"
}

→runConfigure を使用してビルドを構成したので、Haiku にインストール固有の手順を指示する必要はありません。その後、後始末をしています。

(18). 「TEST()」は、ビルド結果に対してテストを実行します

TEST()
{
    make check
}

(19). 最終的な「sed-4.4.recipe」

> cat > cd ~/Git/haikuports/sys-apps/sed/sed-4.4.recipe

SUMMARY="The famous stream editor"
DESCRIPTION="Sed is a stream editor, i.e. it can be used to perform basic \
text transformations on an input stream (a file or input from a pipeline).
While in some ways similar to an editor which permits scripted edits (such as \
ed), sed works by making only one pass over the input(s), and is consequently \
more efficient. But it is sed's ability to filter text in a pipeline which \
particularly distinguishes it from other types of editors."
HOMEPAGE="https://www.gnu.org/software/sed/"
COPYRIGHT="1989-2017 Free Software Foundation, Inc."
LICENSE="GNU GPL v3"
REVISION="4"
SOURCE_URI="https://ftpmirror.gnu.org/sed/sed-$portVersion.tar.xz
    https://ftp.gnu.org/gnu/sed/sed-$portVersion.tar.xz"
CHECKSUM_SHA256="cbd6ebc5aaf080ed60d0162d7f6aeae58211a1ee9ba9bb25623daa6cd942683b"
PATCHES="sed-$portVersion.patchset"

ARCHITECTURES="all !x86_gcc2 ?arm"
if [ "$targetArchitecture" = x86_gcc2 ]; then
SECONDARY_ARCHITECTURES="x86"
fi

commandBinDir=$binDir
if [ "$targetArchitecture" = x86_gcc2 ]; then
    commandBinDir=$prefix/bin
fi

PROVIDES="
    sed$secondaryArchSuffix = $portVersion compat >= 4
    cmd:sed = $portVersion compat >= 4
    "
REQUIRES="
    haiku$secondaryArchSuffix
    "
if [ -n "$secondaryArchSuffix" ]; then
CONFLICTS="
    sed
    "
fi

BUILD_REQUIRES="
    haiku${secondaryArchSuffix}_devel
    "
BUILD_PREREQUIRES="
    cmd:awk
    cmd:g++$secondaryArchSuffix
    cmd:grep
    cmd:ld$secondaryArchSuffix
    cmd:make
    "

TEST_REQUIRES="
    cmd:cmp
    "

defineDebugInfoPackage sed$secondaryArchSuffix \
    "$commandBinDir"/sed


BUILD()
{
    runConfigure --omit-dirs binDir ./configure --bindir="$commandBinDir" \
        --enable-regex-tests --without-included-regex \
        --disable-rpath --with-gnu-ld
    make $jobArgs
}

INSTALL()
{
    make install
    rm "$libDir"/charset.alias
    rmdir "$libDir"
}

TEST()
{
    make check
}

→「sed-4.4.recipe」ファイルが上記と一致することを確認してください。

今回は、REVISION="4" に修正しただけです。

4). レシピをビルドしてパッケージ化

(1). レシピファイルができたので、それをビルドしてみます:

パッケージのバージョンが指定されていることに注目

> hp sed-4.4
:

> hp sed-4.4
:
Checking if any dependency-infos need to be updated ...
Looking for stale dependency-infos ...
Warning: building obsolete port, packages will be put in /boot/home/Git/haikuports/packages/.obsolete
Checking if any dependency-infos need to be updated ...
        updating dependency infos of sed-4.4
Looking for stale dependency-infos ...
        removing sed-4.8.DependencyInfo
        removing sed_debuginfo-4.8.DependencyInfo
        removing sed_source-4.8.DependencyInfo
----------------------------------------------------------------------
sys-apps::sed-4.4
        /boot/home/Git/haikuports/sys-apps/sed/sed-4.4.recipe
----------------------------------------------------------------------

Downloading: https://ftpmirror.gnu.org/sed/sed-4.4.tar.xz ...
--2022-02-14 22:23:22--  https://ftpmirror.gnu.org/sed/sed-4.4.tar.xz
ftpmirror.gnu.org をDNSに問いあわせています... 2001:470:142:5::200, 209.51.188.200
ftpmirror.gnu.org|2001:470:142:5::200|:443 に接続しています... 失敗しました: Network is unreachable.
ftpmirror.gnu.org|209.51.188.200|:443 に接続しています... 接続しました。
HTTP による接続要求を送信しました、応答を待っています... 302 Moved Temporarily
場所: https://ftp.jaist.ac.jp/pub/GNU/sed/sed-4.4.tar.xz [続く]
--2022-02-14 22:23:24--  https://ftp.jaist.ac.jp/pub/GNU/sed/sed-4.4.tar.xz
ftp.jaist.ac.jp をDNSに問いあわせています... 2001:df0:2ed:feed::feed, 150.65.7.130
ftp.jaist.ac.jp|2001:df0:2ed:feed::feed|:443 に接続しています... 失敗しました: Network is unreachable.
ftp.jaist.ac.jp|150.65.7.130|:443 に接続しています... 接続しました。
HTTP による接続要求を送信しました、応答を待っています... 200 OK
長さ: 1181664 (1.1M) [application/x-xz]
`/boot/home/Git/haikuports/sys-apps/sed/download/sed-4.4.tar.xz' に保存中
     0K ........ ........ ..                                 100%  763K=1.5s
2022-02-14 22:23:26 (763 KB/s) - `/boot/home/Git/haikuports/sys-apps/sed/download/sed-4.4.tar.xz' へ保存完了 [1181664/1181664]
Validating checksum of sed-4.4.tar.xz
Unpacking source of sed-4.4.tar.xz
Initialized empty Git repository in /boot/home/Git/haikuports/sys-apps/sed/work-4.4/sources/sed-4.4/.git/
Applying patchset "/boot/home/Git/haikuports/sys-apps/sed/patches/sed-4.4.patchset" ...
Applying: applying patch sed-4.2.1.patch
chroot has these packages active:
        /boot/system/packages/bash-5.1.008-1-x86_64.hpkg
        /boot/system/packages/binutils-2.31.1-2-x86_64.hpkg
        /boot/system/packages/brotli-1.0.9-2-x86_64.hpkg
        /boot/system/packages/bzip2-1.0.8-1-x86_64.hpkg
        /boot/system/packages/ca_root_certificates-2021_07_05-1-any.hpkg
        /boot/system/packages/coreutils-9.0-6-x86_64.hpkg
        /boot/system/packages/dav1d-0.9.2-1-x86_64.hpkg
        /boot/system/packages/enca-1.19-2-x86_64.hpkg
        /boot/system/packages/expat-2.4.3-1-x86_64.hpkg
        /boot/system/packages/fdk_aac-2.0.2-2-x86_64.hpkg
        /boot/system/packages/ffmpeg-4.2.2-9-x86_64.hpkg
        /boot/system/packages/fontconfig-2.13.92-1-x86_64.hpkg
        /boot/system/packages/freetype-2.11.0-3-x86_64.hpkg
        /boot/system/packages/fribidi-1.0.11-1-x86_64.hpkg
        /boot/system/packages/game_music_emu-0.6.3-1-x86_64.hpkg
        /boot/system/packages/gawk-5.1.1-1-x86_64.hpkg
        /boot/system/packages/gcc-11.2.0_2021_07_28-5-x86_64.hpkg
        /boot/system/packages/gcc_syslibs-11.2.0_2021_07_28-5-x86_64.hpkg
        /boot/system/packages/gettext_libintl-0.19.8.1-7-x86_64.hpkg
        /boot/system/packages/giflib-5.2.1-1-x86_64.hpkg
        /boot/system/packages/gmp-6.2.1-2-x86_64.hpkg
        /boot/system/packages/graphite2-1.3.14-1-x86_64.hpkg
        /boot/system/packages/grep-3.6-2-x86_64.hpkg
        /boot/system/packages/gutenprint8-5.3.1-2-x86_64.hpkg
        /boot/system/packages/gzip-1.10-1-x86_64.hpkg
        /boot/system/packages/haiku-r1~beta3_hrev55874-1-x86_64.hpkg
        /boot/system/packages/haiku_datatranslators-r1~beta3_hrev55874-1-x86_64.hpkg
        /boot/system/packages/haiku_devel-r1~beta3_hrev55874-1-x86_64.hpkg
        /boot/system/packages/harfbuzz-2.8.1-1-x86_64.hpkg
        /boot/system/packages/icu66-66.1-2-x86_64.hpkg
        /boot/system/packages/intel_wifi_firmwares-2019_11_02-1-any.hpkg
        /boot/system/packages/jasper-2.0.16-4-x86_64.hpkg
        /boot/system/packages/lame-3.100-3-x86_64.hpkg
        /boot/system/packages/lcms-2.12-1-x86_64.hpkg
        /boot/system/packages/libass-0.15.1-1-x86_64.hpkg
        /boot/system/packages/libavif-0.8.4-2-x86_64.hpkg
        /boot/system/packages/libedit-20210419_3.1-1-x86_64.hpkg
        /boot/system/packages/libicns-0.8.1-8-x86_64.hpkg
        /boot/system/packages/libiconv-1.16-1-x86_64.hpkg
        /boot/system/packages/libjpeg_turbo-2.1.1-1-x86_64.hpkg
        /boot/system/packages/libogg-1.3.5-1-x86_64.hpkg
        /boot/system/packages/libopenmpt-0.5.13-1-x86_64.hpkg
        /boot/system/packages/libpcre-8.45-1-x86_64.hpkg
        /boot/system/packages/libpng16-1.6.37-1-x86_64.hpkg
        /boot/system/packages/libraw-0.19.5-3-x86_64.hpkg
        /boot/system/packages/libsolv-0.3.0_haiku_2014_12_22-3-x86_64.hpkg
        /boot/system/packages/libtheora-1.1.1-7-x86_64.hpkg
        /boot/system/packages/libvorbis-1.3.7-1-x86_64.hpkg
        /boot/system/packages/libvpx-1.10.0-1-x86_64.hpkg
        /boot/system/packages/libwebp-1.2.1-1-x86_64.hpkg
        /boot/system/packages/libxml2-2.9.12-1-x86_64.hpkg
        /boot/system/packages/make-4.1-5-x86_64.hpkg
        /boot/system/packages/mpc-1.2.1-1-x86_64.hpkg
        /boot/system/packages/mpfr-4.1.0-1-x86_64.hpkg
        /boot/system/packages/ncurses6-6.2-1-x86_64.hpkg
        /boot/system/packages/noto-20200106-1-any.hpkg
        /boot/system/packages/noto_sans_cjk_jp-1.004-2-any.hpkg
        /boot/system/packages/openexr-2.4.1-1-x86_64.hpkg
        /boot/system/packages/openjpeg-2.4.0-1-x86_64.hpkg
        /boot/system/packages/openssl-1.1.1m-1-x86_64.hpkg
        /boot/system/packages/opus-1.3.1-1-x86_64.hpkg
        /boot/system/packages/ralink_wifi_firmwares-2015_02_11-1-any.hpkg
        /boot/system/packages/readline-8.1-1-x86_64.hpkg
        /boot/system/packages/realtek_wifi_firmwares-2019_01_02-1-any.hpkg
        /boot/system/packages/sed-4.8-1-x86_64.hpkg
        /boot/system/packages/snappy-1.1.8-1-x86_64.hpkg
        /boot/system/packages/soxr-0.1.3-1-x86_64.hpkg
        /boot/system/packages/speex-1.2.0-4-x86_64.hpkg
        /boot/system/packages/tar-1.34-1-x86_64.hpkg
        /boot/system/packages/tiff4-4.2.0-1-x86_64.hpkg
        /boot/system/packages/unzip-6.10c23-4-x86_64.hpkg
        /boot/system/packages/wavpack-5.4.0-1-x86_64.hpkg
        /boot/system/packages/which-2.21-6-x86_64.hpkg
        /boot/system/packages/xz_utils-5.2.5-1-x86_64.hpkg
        /boot/system/packages/zlib-1.2.11-4-x86_64.hpkg
        /boot/system/packages/zstd-1.5.0-2-x86_64.hpkg
----- Package Info ----------------
header size:                     80
heap size:                      790
TOC size:                        41
package attributes size:        839
total size:                     870
-----------------------------------
----- Package Info ----------------
header size:                     80
heap size:                      849
TOC size:                        41
package attributes size:        945
total size:                     929
-----------------------------------
waiting for build package sed-4.4-4 to be activated
waiting for build package sed_debuginfo-4.4-4 to be activated
Building ...
checking for a BSD-compatible install... /bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking whether make supports nested variables... (cached) yes
checking whether make supports the include directive... yes (GNU style)
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether the compiler supports GNU C... yes
checking whether gcc accepts -g... yes
checking for gcc option to enable C11 features... none needed
checking dependency style of gcc... gcc3
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for sys/param.h... yes
checking for stdio_ext.h... yes
checking for getopt.h... yes
checking for sys/time.h... yes
checking for sys/socket.h... yes
checking for langinfo.h... yes
checking for limits.h... yes
checking for xlocale.h... no
checking for sys/mman.h... yes
checking for malloc.h... yes
checking for selinux/selinux.h... no
checking for wchar.h... yes
checking for features.h... yes
checking for wctype.h... yes
checking for dirent.h... yes
checking for locale.h... yes
checking for errno.h... yes
checking for mcheck.h... no
checking for minix/config.h... no
checking whether it is safe to define __EXTENSIONS__... yes
checking whether _XOPEN_SOURCE should be defined... no
checking how to run the C preprocessor... gcc -E
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
:
make[1]: Leaving directory '/sources/sed-4.4'

/packages/sed_debuginfo-4.4-4/.self
name                    sed
version                 4.4-4
architecture            x86_64
summary                 "The famous stream editor"
description             "Sed is a stream editor, i.e. it can be used to perform basic text transformations on an input stream (a file or input from a pipeline).
While in some ways similar to an editor which permits scripted edits (such as ed), sed works by making only one pass over the input(s), and is consequently more efficient. But it is sed's ability to filter text in a pipeline which particularly distinguishes it from other types of editors."
packager                "FuRuYa7 <mymail@mydomain.org>"
vendor                  "Haiku Project"
licenses {
        "GNU GPL v3"
}
copyrights {
        "1989-2017 Free Software Foundation, Inc."
}
provides {
        sed = 4.4 compat >= 4
        cmd:sed = 4.4 compat >= 4
}
requires {
        haiku >= r1~beta3_hrev55874-1
}
urls {
        "https://www.gnu.org/software/sed/"
}
source-urls {
# Download
        "https://ftpmirror.gnu.org/sed/sed-4.4.tar.xz"
# Location 2
        "https://ftp.gnu.org/gnu/sed/sed-4.4.tar.xz"
}
mimesetting files for package sed-4.4-4-x86_64.hpkg ...
creating package sed-4.4-4-x86_64.hpkg ...
----- Package Info ----------------
header size:                     80
heap size:                   124460
TOC size:                       454
package attributes size:        788
total size:                  124540
-----------------------------------
name                    sed_debuginfo
version                 4.4-4
architecture            x86_64
summary                 "The famous stream editor (debug info)"
description             "Sed is a stream editor, i.e. it can be used to perform basic text transformations on an input stream (a file or input from a pipeline).
While in some ways similar to an editor which permits scripted edits (such as ed), sed works by making only one pass over the input(s), and is consequently more efficient. But it is sed's ability to filter text in a pipeline which particularly distinguishes it from other types of editors."
packager                "FuRuYa7 <mymail@mydomain.org>"
vendor                  "Haiku Project"
licenses {
        "GNU GPL v3"
}
copyrights {
        "1989-2017 Free Software Foundation, Inc."
}
provides {
        sed_debuginfo = 4.4
        "debuginfo:sed(sed)" = 4.4
}
requires {
        sed == 4.4 base
}
urls {
        "https://www.gnu.org/software/sed/"
}
source-urls {
# Download
        "https://ftpmirror.gnu.org/sed/sed-4.4.tar.xz"
# Location 2
        "https://ftp.gnu.org/gnu/sed/sed-4.4.tar.xz"
# Location 3
        "https://ports-mirror.haiku-os.org/sed/sed-4.4.tar.xz"
}
mimesetting files for package sed_debuginfo-4.4-4-x86_64.hpkg ...
creating package sed_debuginfo-4.4-4-x86_64.hpkg ...
----- Package Info ----------------
header size:                     80
heap size:                   128843
TOC size:                       231
package attributes size:        853
total size:                  128923
-----------------------------------
waiting for build package sed-4.4-4 to be deactivated
waiting for build package sed_debuginfo-4.4-4 to be deactivated
grabbing sed-4.4-4-x86_64.hpkg and moving it to /boot/home/Git/haikuports/packages/.obsolete/sed-4.4-4-x86_64.hpkg
grabbing sed_debuginfo-4.4-4-x86_64.hpkg and moving it to /boot/home/Git/haikuports/packages/.obsolete/sed_debuginfo-4.4-4-x86_64.hpkg

→パッケージ名が「sed-4.4-4」になっていることに注目。最後の数字の「4」はREVISION="4" の「4」です。

パッケージ自体とdebuginfo パッケージの2つのパッケージが生成されました。

(2). 生成されたパッケージの場所を確認：

> ls /boot/home/Git/haikuports/packages/.obsolete/sed-4.4-4-x86_64.hpkg
/boot/home/Git/haikuports/packages/.obsolete/sed-4.4-4-x86_64.hpkg

> ls /boot/home/Git/haikuports/packages/.obsolete/sed_debuginfo-4.4-4-x86_64.hpkg
/boot/home/Git/haikuports/packages/.obsolete/sed_debuginfo-4.4-4-x86_64.hpkg

→ちなみに「obsolete」は「廃止」を意味します。バージョンが低いからだろうと思われます。

(3). システムにインストールされている「sed」のバージョンを確認:

> pkgman search sed
S       sed                                   The famous stream editor                                            
        sed_debuginfo                         The famous stream editor (debug info)                               
        sed_source                            The famous stream editor (source files)

> sed --version
sed (GNU sed) 4.8

5). パッケージをインストール:

「~/config/packages」ディレクトリにパッケージを移動します:

> cd /tmp
> cp /boot/home/Git/haikuports/packages/.obsolete/sed-4.4-4-x86_64.hpkg .

> ls -1 /tmp
dbus-mcSRvct5NS
Otter-d4908abe9cdf2760dee5776c5cebec98
sed-4.4-4-x86_64.hpkg
tracker
usb_hid_report_descriptor_80ee_0021_0.bin

> cp /tmp/sed-4.4-4-x86_64.hpkg  /boot/home/config/packages/

→移動する前に「/tmp」にコピーした理由

パッケージをコピーするのではなく、システムドライブから移動した理由:

「パッケージデーモンはpackage ディレクトリを監視し、新しいパッケージファイルを検出すると、それをアクティブ化しようとします。デーモンがコピーを完了する前にパッケージを処理しようとすると、無効として検出され、無視されます。

しばらく前に、デーモンがアクションを実行する前に 0.5秒の遅延を導入して、複数のファイルが移動されたときにそれらが一緒に処理されるようにしました。したがって、0.5秒以内に完了する限り、コピーは機能します。

しかしそれは安全ではありません。正式にはサポートされていません。」

6). 動作確認:

> ls /boot/home/config/packages/
administrative
sed-4.4-4-x86_64.hpkg

> ls /boot/home/config/bin/
sed

> /boot/home/config/bin/sed --version
/boot/home/config/bin/sed (GNU sed) 4.4

7). パッケージをアンインストール:

「~/config/packages/」ディレクトリからパッケージを削除しました:

> rm /boot/home/config/packages/sed-4.4-4-x86_64.hpkg
> ls /boot/home/config/bin/
>

--- - --- - --- - --- - --- - --- - --- - --- - --- - --- - --- - ----- ---

6. 環境変数の説明の「HaikuPorter-BuildRecipes wiki」を参照してみる:

参考:

「BuildRecipes」

環境変数は、Haiku のレシピファイルを作成するときに使われる重要な情報です。

レシピを作成する

概要

レシピファイルは、特定のバージョンのポートをビルドする方法と、ビルド結果から作成する必要があるパッケージに関する特定の詳細をHaikuPorter に通知する特別な種類のシェルスクリプトです。

HaikuPorter とレシピ（ビルドレシピスクリプト) の間には、双方向の「通信」（環境変数とシェル関数を使用）があります。

入力（HaikuPorter →レシピファイルの作成）

環境変数のセットはHaikuPorter によって設定され、呼び出し時にスクリプトに渡されます。これらの変数は、ビルド構成の詳細を調整するためにレシピスクリプトで検査できます。最も注目すべきは、多くの変数が、ビルドによってファイルが配置されるディレクトリに対応していることです。

さらに、いくつかのシェル関数がレシピスクリプトで利用できるようになっています。これらの関数は、特定のタスク（configure スクリプトの呼び出しやビルドされた静的ライブラリの処理など）を実行するためにレシピから呼び出すことができます（そして呼び出す必要があります）。

出力（レシピファイルの作成 →HaikuPorter）

ビルドの詳細に関する情報をHaikuPorter に返すには、レシピスクリプトによっていくつかの環境変数を初期化する必要があります。

さらに、さまざまなビルドの段階を実現するシェル関数は、レシピスクリプトで定義する必要があります。 HaikuPorter は、必要に応じてこれらの関数を呼び出します（たとえば、ポートの構築に使用される実際のコマンドは、BUILD という名前のシェル関数で定義する必要があります）。

入力の環境変数

HaikuPorter からレシピファイルに渡されるほとんどの環境変数は、ビルドの処理で作成された特定のタイプのファイルを配置するためのディレクトリを定義します。

ビルドの処理で絶対パスが必要な場合は常にHaikuPorter は、package-links フォルダーを使用して実際のインストールパスを抽象化し、インストールされているパッケージフォルダ（例：/boot/home/config/packages）の位置に関係なく、結果のパッケージが機能するようにします。

追記: パッケージ化したとき、パッケージを（誰が）どこにインストールするかはまだ決まっていません。インストール場所が変っても（誰がインストールしても）正常に動くようにしなくてはなりません。なので、絶対パスでしか指定できないときは工夫が必要です。つまり、以下の環境変数を利用します。

--- - --- - --- - --- - --- - --- - --- - --- - --- - --- - --- - ----- ----

6-1. 参考: 入力の環境変数の一覧:

レシピファイルの中で使われている変数です。よく見る変数に ● マークしてます。

入力の環境変数の一覧:

$addOnsDir:

アドオンの絶対ディレクトリ

$appsDir:　●

アプリケーションの絶対ディレクトリ

$binDir:

バイナリの絶対ディレクトリ

$buildArchitecture:

Haiku アーキテクチャ

（例: x86_gcc2）

$configureDirArgs:

すべての標準構成オプションとそれぞれの値を含む文字列

→これは、構成するすべての個々の変数を渡す代わりに使用できます（ただし、代わりに「runConfigure()」を使用する必要があります）

$configureDirVariables:

すべてのディレクトリ変数名の名前のスペースで区切られたリストを含む文字列

$dataDir:　●

データの絶対ディレクトリ

$dataRootDir:

データの絶対ベースディレクトリ。 Haiku では、これは $dataDir と同じです

$debugInfoDir:

デバッグ情報ファイルのディレクトリへの絶対パス

$developDir:

その下にすべての開発関連ファイルを配置する必要があるディレクトリへの絶対パス

$developDocDir:

構築中のポートに固有の開発関連ドキュメントの絶対ベースディレクトリ

→html またはpdf 形式のドキュメントはここに配置する必要があり、マンページは $manDir に配置する必要があります

$developLibDir:

開発ライブラリ（つまり、develパッケージによって提供される静的ライブラリと共有ライブラリ）の絶対ディレクトリ

→実行時に必要な共有ライブラリはここには属していません。$libDir に配置する必要があります

$docDir:

構築中のポートに固有の（開発以外の）ドキュメントの絶対ベースディレクトリ

→ html または pdf 形式のドキュメントはここに配置する必要があり、マンページは $manDir に配置する必要があります

$documentationDir:

その下にすべてのドキュメントを配置する必要がある絶対ベースディレクトリ

→これはポート固有のディレクトリではありません

$fontsDir:

フォントの絶対ディレクトリ

$includeDir:

ヘッダーファイルの絶対ディレクトリ

$infoDir:

情報形式のドキュメントの絶対ディレクトリ（Haiku ポートでは嫌われています）

$installDestDir:

すべての絶対インストールパスの前に追加される絶対パス（参照が解除された場合、つまり通常は「INSTALL」関数でのみ）

→「make install」の場合は「DESTDIR」として設定する必要があります。これは、HaikuPorts クロスビルディングリポジトリでのみ実行する必要があります

$isCrossRepository:

使用されているポートツリーがブートストラップパッケージのクロスビルドを処理するものである場合はtrue です

$jobArgs:　●

「HaikuPorter --jobs=」で呼び出された場合、これには make に適用可能なジョブ番号の指定が含まれます（つまり「-j」）

$jobs:

同時に実行するビルドジョブの数（プロセッサの数よりも下）。これは「haikuporter --jobs=」で設定できます

$libDir:

実行時に（つまり、Haiku のランタイムローダーによって）使用される共有ライブラリの絶対ディレクトリ

$libExecDir:

ポートが内部で呼び出す可能性のある実行可能ファイルの絶対ディレクトリ

→Haiku では、これは $libDir と同じです

$localStateDir:

実行時に作成されたファイルを配置するための絶対ディレクトリ

→これは var-hierarchy に対応します

$manDir:

マニュアルページの絶対ディレクトリ

→man セクションごとに、このディレクトリの下にサブディレクトリが存在します

$oldIncludeDir:

ヘッダーファイルを配置するための絶対ディレクトリの別名（$includeDir）

$portBaseDir:

このビルドレシピファイルの絶対ディレクトリ（ビルドホスト上！）

→これは、他のポートへのローカル（つまり、「file:///-」）URL を使用する場合に役立ちます。例として、ローカルURL を使用してbinutils ポートのソースディレクトリを参照する gcc-recipe があります（どちらも同じ git リポジトリにあります）

$portDir:

現在のポートのファイル（パッチ、ライセンス、レシピ）を見つけることができる絶対ディレクトリ（ビルドホスト上！）

$portFullVersion:

リビジョンを含む現在のポートのフルバージョン

（例: 2.14-1）

$portName:

現在のポートの名前

$portPackageLinksDir:

このポートのベース（メイン）パッケージのpackage-links ディレクトリへの絶対パス

→これは、現在のポートが絶対パスを介して別の（必須の）ポートからファイルを参照する必要がある場合に役立ちます。繰り返しになりますが、これはパッケージリンクの抽象化を利用して、特定のパッケージがインストールされている場所に関係なく、これらのクロスパッケージ参照が機能するようにします

$portRevision:

現在のポートのリビジョン

（例: 1）

$portRevisionedName:

バージョンとリビジョンによって拡張された現在のポートの名前

（例: grep-2.14-1）

$portVersion:　●

現在のポートのバージョン

（例: 2.14）

$portVersionedName:

バージョンによって拡張された現在のポートの名前

（例: grep-2.14）

$postInstallDir:

インストール後のスクリプトの絶対ディレクトリ

$preferencesDir:

環境設定の絶対ディレクトリ

$prefix:

ポートの絶対ベースディレクトリ（つまり、インストール場所）

$relativeAddOnsDir:

インストール場所指定(prefix) の相対ディレクトリとしての $addOnsDir

$relativeAppsDir:

インストール場所指定(prefix) の相対ディレクトリとしての $appsDir

$relativeBinDir:

インストール場所指定(prefix) の相対ディレクトリとしての $binDir

$relativeDataDir:

インストール場所指定(prefix) の相対ディレクトリとしての $dataDir

$relativeDataRootDir:

インストール場所指定(prefix) の相対ディレクトリとしての $dataRootDir

$relativDebugInfoDir:

インストール場所指定(prefix) の相対ディレクトリとしての $debugInfoDir

$relativeDevelopDir:

インストール場所指定(prefix) の相対ディレクトリとしての $developDir

$relativeDevelopDocDir:

インストール場所指定(prefix) の相対ディレクトリとしての $developDocDir

$relativeDevelopLibDir:

インストール場所指定(prefix) の相対ディレクトリとしての $developLibDir

$relativeDocDir:

インストール場所指定(prefix) の相対ディレクトリとしての $docDir

$relativeDocumentationDir:

インストール場所指定(prefix) の相対ディレクトリとしての $ documentationDir

$relativeFontsDir:

インストール場所指定(prefix) の相対ディレクトリとしての $fontsDir

$relativeIncludeDir:

インストール場所指定(prefix) の相対ディレクトリとしての $includeDir

$relativeInfoDir:

インストール場所指定(prefix) の相対ディレクトリとしての $infoDir

$relativeLibDir:

インストール場所指定(prefix) の相対ディレクトリとしての $libDir

$relativeLocalStateDir:

インストール場所指定(prefix) の相対ディレクトリとしての $localStateDir

$relativeManDir:

インストール場所指定(prefix) の相対ディレクトリとしての $manDir

$relativeOldIncludeDir:

インストール場所指定(prefix) の相対ディレクトリとしての $oldIncludeDir

$relativePostInstallDir:

インストール場所指定(prefix) の相対ディレクトリとしての $postInstallDir

$relativePreferencesDir:

インストール場所指定(prefix) の相対ディレクトリとしての $preferencesDir

$relativeSbinDir:

インストール場所指定(prefix) の相対ディレクトリとしての $binDir

$relativeSettingsDir:

インストール場所指定(prefix) の相対ディレクトリとしての $settingsDir

$relativeSharedStateDir:

インストール場所指定(prefix) の相対ディレクトリとしての $sharedStateDir

$sbinDir:

スーパーユーザーバイナリの絶対ディレクトリ。 Haikuでは、これは $binDir と同じです

$settingsDir:

設定ファイルの絶対ディレクトリ

$sharedStateDir:

共有状態ファイルの絶対ディレクトリ

→ Haiku では、これは $localStateDir と同じです。つまり、var の階層に対応します

$sourceDir:

ビルドのソースディレクトリへの絶対パス

→ これには、実際のビルドプロセスを実装するファイル（configure、Makefileなど）が含まれています

$targetArchitecture:

HaikuPorter の現在のポートが構築されている Haiku アーキテクチャ

（例: x86_gcc2）

→ 使用中のポートツリーがクロスビルドに関連するものでない限り、これは $buildArchitecture と同じです

クロスビルドのports ツリーがアクティブな場合、使用可能な変数:

buildMachineTriple:

HaikuPorterが実行されているマシンのマシントリプル

（例: i586-pc-haiku_gcc2）

buildMachineTripleAsName:

定義を requires/provides で使用できる名前としてHaikuPorter が実行されているマシンのマシントリプル

（例: i586_pc_haiku_gcc2）

crossSysrootDir:

cross-sysrootディレクトリ（クロスビルドの場合のみ）

（例: /boot/cross-sysroot/x86_gcc2）

targetMachineTriple:

このポートが構築されているマシンのマシントリプル

（例: i586-pc-haiku_gcc2）

targetMachineTripleAsName:

このポートが requires/Provides 定義で使用可能な名前として構築されているマシンのマシントリプル

（例: i586_pc_haiku_gcc2）

記述されていた、実現したいこと:

上記のすべての変数に、ある種のprefix （インストール場所）を指定できると便利です。そうしないと、特定のポートで使用される実際のビルドの処理と名前空間が衝突する可能性があります（例: git）

--- - --- - --- - --- - --- - --- - --- - --- - --- - --- - --- - ----- -----

6-2. 参考: 入力のシェル関数の一覧:

シェル関数は、レシピファイル（ビルドレシピスクリプト）で使用できるようにするためにHaikuPorter によって定義されています。

シェル関数の一覧:

addAppDeskbarSymlink()

使用法: addAppDeskbarSymlink []

目的: アプリケーションのデスクバーシンボリックリンクを作成します。

パラメータ:

appPath: アプリケーション実行可能ファイルへの絶対パス。

entryName: デスクバーに表示されるアプリケーションの名前。

省略できます。その場合、アプリケーション実行可能ファイルのファイル名が使用されます。

addPreferencesDeskbarSymlink()

使用法: defineDebugInfoPackage [--directory ] ...

目的: 別のパッケージのデバッグ情報パッケージを定義します。トップレベルで呼び出す必要があります（つまり、アクション関数の1つでは呼び出されません）。指定された基本パッケージには、デバッグ情報を抽出するための指定されたファイルが含まれています。インストールフェーズの最後（つまり、「INSTALL」が戻った後）に、デバッグ情報が個別のファイルに抽出され、それぞれのデバッグ情報パッケージに移動されます。

パラメータ:

toDirectory: デバッグ情報ファイルが配置されるディレクトリへのパス。デフォルトは $debugInfoDir です。

basePackageName: ファイルが属する基本パッケージの名前。

これにより、デバッグ情報パッケージの名前（_debuginfo）とその依存関係も定義されます。

path: デバッグ情報の抽出元となるファイルへのパス。任意の数のファイルを指定できます。

extractDebugInfo()

使用法: extractDebugInfo <パス>

目的: ファイルからデバッグ情報ファイルにデバッグ情報を抽出します。

パラメータ:

path: デバッグ情報を抽出するファイルへのパス。

debugInfoPath: 作成されるデバッグ情報ファイルのパス。

必要に応じて、含まれているディレクトリ（および欠落しているすべての祖先ディレクトリ）が作成されます。

fixDevelopLibDirReferences()

使用法: fixDevelopLibDirReferences <ファイル> ...

目的: 指定されたファイル内の $libDir のインスタンスを $developLibDir に置き換えます。これは、開発ライブラリの場所に関して-config スクリプトを修正する場合に役立ちます。通常、ライブラリは $libDir にあると信じていますが、Haiku では $developLibDir にあります。

fixPkgconfig()

使用法: fixPkgconfig

目的: pkgconfig-subfolder を $libDir から $developLibDir に移動し、そこにあるすべてのファイルを調整して、$prefix/development/lib を介してライブラリを参照し、 $prefix/development/headers を介してヘッダーを参照します。

packageEntries()

使用法: packageEntries ...

目的: 指定されたエントリを、packageSuffix で指定された兄弟パッケージのパッケージディレクトリに移動します。実際には、指定されたエントリはメインパッケージに入れられませんが、代わりに兄弟パッケージに入れられます。

パラメータ:

packageSuffix: エントリの移動先となる兄弟パッケージのサフィックス。

entry: メインパッケージから兄弟パッケージに移動する単一のエントリを指定します。指定されたエントリパスは、絶対パスでも $prefixからの相対パスでもかまいません。

prepareInstalledDevelLib()

使用法: prepareInstalledDevelLib [ []]

目的: soPattern と一致する場合、指定されたベース名に一致するすべてのライブラリを $libDir から $developLibDir にシンボリックリンクし、残り（静的ライブラリなど）を $developLibDir に移動します。

パラメータ:

libBaseName: ライブラリのベース名。例:  「libfoo」

soPattern: 共有ライブラリエントリを列挙するために使用されるグロブパターン。

完全なパターンを形成するために $libDir/${libBaseName} に追加されます。デフォルトは「.so*」です。

pattern: すべてのライブラリエントリを列挙するために使用される glob パターン。

完全なパターンを形成するために $libDir/${libBaseName} に追加されます。デフォルトは「.*」です。

prepareInstalledDevelLibs()

使用法: prepareInstalledDevelLibs ...

目的: 指定されたすべてのライブラリベース名に対して prepareInstalledDevelLib() を呼び出します（soPattern および pattern のデフォルトを使用）

runConfigure()　●

使用法: runConfigure [ --omit-dirs ] ...

目的: 正しいディレクトリ引数を使用して configure スクリプトを呼び出すヘルパー関数

パラメータ:

dirsToOmit: 構成に渡されないディレクトリ引数のスペース区切りのリスト。

例: 「docDirmanDir」（単一の引数として！）。

configure: 呼び出されるconfigureプログラム。

argsToConfigure: 構成に渡される追加の引数。

--- - --- - --- - --- - --- - --- - --- - --- - --- - --- - --- - ----- ----- -

6-3. 参考: 出力の環境変数の一覧:

これらは、HaikuPorterによって認識されるグローバル（つまり、ポートごとに1つのインスタンス）環境変数です-

BUILD_PACKAGE_ACTIVATION_PHASE

タイプ: 文字列-['BUILD'、 'TEST'、または 'INSTALL'] のいずれか

目的: ビルドパッケージをアクティブ化するビルドフェーズをHaikuPorter に通知します。デフォルトでは、これはBUILDフェーズの直前に発生しますが、ポートがビルド中に独自のバイナリを実行できることに依存している場合（autoconf は例です）、これは後のフェーズ（通常は INSTALL）で発生する必要があります。

必須: いいえ

デフォルト: 'BUILD'

BUILD_PACKAGE_ACTIVATION_PHASE

タイプ: 文字列-['BUILD'、 'TEST'、または 'INSTALL'] のいずれか

必須: いいえ

デフォルト: 'BUILD'

DISABLE_SOURCE_PACKAGE

タイプ: YesNo-['yes'、 'true'、 'no'、 'false'] のいずれか、大文字と小文字を区別しない

目的: 通常、HaikuPorter はすべてのポートのソースパッケージを作成します。このオプションを使用して、そのソースパッケージの作成を無効にすることができます。これは主に、ソースと結果のパッケージがほとんど同じであるパッケージに使用されます。主な2つのケースは、既存のバイナリをカプセル化するだけのパッケージと、コンパイルする必要のないスクリプトのみを含むパッケージです。

必須: いいえ

デフォルト: 'no'

HOMEPAGE

タイプ: URL のリスト（1行に1つ）

目的: このポートのホームページである1つ以上のWeb サイトを指定します。

必須: はい

デフォルト: なし

MESSAGE

タイプ: 文字列

目的: このポートが構築される前に、ユーザー（つまり、パッケージャー）によって表示および確認されるメッセージを指定します。

必須: いいえ

デフォルト: なし

REVISION

タイプ: 正の整数

目的: ビルドレシピのリビジョンを定義します（これは、ポートのバージョンへの追加です）。ビルドされたパッケージに影響を与えるレシピで何かが変更されるたびに（基本的にビルドレシピが変更されるたびに）、この数を増やす必要があります。さらに、パッチファイルが変更されるたびに、この数もインクリメントする必要があります。

必須: はい

デフォルト: 1

定義されたソースアーカイブごとに次の環境変数のセットが存在します。

最初の変数のセットはここに示すように名前が付けられ、2番目のセットは「2」が付いて、3番目は「3」が付きます。

注: ほとんどのポートにはソースアーカイブが1つしかないため、追加のセットは必要ありません。

CHECKSUM_SHA256

タイプ: SHA256-チェックサム

目的: ダウンロードしたソースアーカイブを検証するために HaikuPorter が使用する SHA256 チェックサムを定義します。

必須: はい。ただし、ポートがソースアーカイブを使用しない場合（たとえば、ソースがバージョン管理リポジトリから読み込まれる場合）。

デフォルト: なし

PATCHES

タイプ: 文字列

目的: このポートのソースに適用する 1つ以上のパッチファイルを指定します。これは、ソースアーカイブ（および対応するパッチセット）を使用してポート用に作成された暗黙の git リポジトリを利用するために非推奨になりました。

必須: いいえ

デフォルト: なし

ADDITIONAL_FILES

タイプ: 文字列

目的: ポートを構築するときに「$portDir/additional-files」で使用できるようにする 1つ以上の追加ファイル（またはディレクトリ）を指定します。ここで提供される名前は、ポートの additional-files ディレクトリに関連しています。例としては、パッチセットを介して提供されていない RDEF ファイルやインストール後のスクリプトがあります。

必須: いいえ

デフォルト: なし

SOURCE_DIR

タイプ: 文字列

目的: ソースアーカイブが解凍された後、ソースが存在するサブディレクトリを指定します。ほとんどのポートは「$portVersionedName」を使用する必要があります。これは、ソースをアーカイブする最も一般的な方法のようです。

ポートが大きなソースアーカイブをプルするが、それ自体のサブディレクトリのみを使用する場合、そのサブディレクトリへの相対パスをここで指定できます（例えば、gcc 2 では「$portVersionedName/legacy/gcc」が使用されます）

指定されたサブディレクトリのコンテンツのみが、ポートのソースパッケージに含まれます。

HaikuPorter は、レシピによって提供されるシェル関数のいずれかを呼び出すと、現在の作業ディレクトリをソースディレクトリに設定します。

必須: いいえ

デフォルト: なし

SOURCE_FILENAME

タイプ: 文字列

目的: ソースアーカイブのローカルファイル名を指定するために使用できます。これは、ソースがフェッチされたURL が適切なファイル名を提供していない場合に役立ちます（例: http://sw.example.org/cool-stuff-1.3/download）

必須: いいえ

デフォルト: なし

SOURCE_URI

タイプ: 文字列

目的: それぞれのソースアーカイブをダウンロードするための1つ以上のURIを指定します。

SOURCE_URI は、複数のURI（1行に1つ）を提供できます。これらはすべて、まったく同じファイルを提供することが期待されています。ポートに複数のソースアーカイブが必要な場合は、SOURCE_URI_2 の 2番目のアーカイブのURI を提供する必要があります。

必須: はい

デフォルト: なし

ダウンロード用のURI タイプ:

ソースアーカイブのダウンロードでは、次の URI タイプがサポートされています。解凍する必要のない、プレーンファイルには、「#noarchive」サフィックスを付ける必要があります。

http:// : wget を介したソースアーカイブのダウンロード

https:// : wget を介したソースアーカイブのダウンロード

ftp:// : wget を介したソースアーカイブのダウンロード

/... : ローカルディスクからのソースアーカイブ（またはファイル）のコピー

チェックアウトのURI タイプ:

ダウンロード時 VCS リポジトリからソースのチェックアウト/クローンを作成するために、次のURI タイプがサポートされています（特定のリビジョンは「#」サフィックスとして指定できます）。

bzr:// : Bazaar リポジトリのチェックアウトを介してダウンロードします。

cvs:// : CVS リポジトリのチェックアウトを介してダウンロードします。必要なCVS モジュールは、URI の最後のパスコンポーネントとして指定する必要があります。

fossil:// : Fossil リポジトリのクローンを介してダウンロードします。

git:// : Gitリポジトリのクローンを作成してダウンロードします。

git+...:// : Gitリポジトリのクローンを作成してダウンロードします。

hg:// : Mercurial リポジトリのクローンを作成してダウンロードします。

hg+...:// : Mercurial リポジトリのクローンを作成してダウンロードします。

svn:// : Subversion リポジトリのチェックアウトを介してダウンロードします。

svn+...:// : Subversion リポジトリのチェックアウトを介してダウンロードします。

最後に、パッケージごとに設定できる出力変数のセットがあります。兄弟パッケージは、これらの変数の1つを「_」で拡張することによって定義できます。

たとえば、foo-recipe で「SUMMARY_devel='Development files for foo'」を設定した場合、兄弟パッケージ「foo_devel」が「foo」という名前の基本パッケージと一緒に作成されます。

各兄弟パッケージは基本パッケージからすべての変数を継承しますが、「_」に値を指定することにより、それらを個別に上書きできます。

これは、パッケージごとの変数のセットです。

ARCHITECTURES

タイプ: ['all'、 'arm'、 'ppc'、 'x86'、 'x86_gcc2'、 'x86_64'、 'any'、 'source'] の1つ以上。スペースで区切られます。

目的: 特定のアーキテクチャでこのポートの状態を指定します。

アーキテクチャ固有のバイナリを持たないパッケージ（Perlスクリプトなど）は「any」でマークされます。
ソースパッケージは「source」でマークされます。
「?」は、各マシンアーキテクチャ固有のコンテンツを含むパッケージの場合を示します。
「!」は、パッケージがそのアーキテクチャでそれぞれテストされていないか壊れていることを示します。
「all」は、すべてのマシンアーキテクチャのステータスを一度に宣言することができます。

（これは、後にアイテムを追加することでオーバーライドできます。たとえば、「all!x86_gcc2」は、レシピがx86_gcc2 を除くすべてのアーキテクチャー用に構築できる、または構築する必要があることを示します。）

例: 「ARCHITECTURES="x86_gcc2 ?x86 !ppc"」は、

x86_gcc2 では、このパッケージが機能することを意味します。 x86 ではテストされていません（ただし、動作することが期待されています）が、ppc では壊れている（動かない）ことがわかっています。

必須: はい

デフォルト: なし

備考: アーキテクチャは、「任意の」または「ソース」、あるいは他の可能な選択肢の 1つ以上の任意の組み合わせである可能性があります。

歴史的な理由から、推奨される順序は ARCHITECTURES="x86_gcc2 x86 x86_64 arm ppc" ですが、ほとんどの場合、arm と ppc については言及されません。

BUILD_PREREQUIRES

タイプ: Multiline-String、1行に1つのrequired_entity-specification（空の行は無視されます）

required_entity の詳細は、BuildingPackages を参照

目的: ビルドプロセス中にビルドホストで実行されるコマンドのセットを定義します。

通常、これは gcc、binutils、make、sed、grep などのツールになります。

必須: いいえ

ディフォルト: ""

BUILD_REQUIRES

タイプ: Multiline-String、1行に 1つの required_entity-specification（空の行は無視されます）

required_entity の詳細は、BuildingPackages を参照

目的: ビルドプロセス中に必要な開発ライブラリのセット（または同様の目的を持つ他のファイル）を定義します。

通常、これは、ビルドされたパッケージが依存するすべてのライブラリに対して1つの開発ライブラリ仕様になります。

必須: いいえ

ディフォルト: ""

CONFLICTS

タイプ: Multiline-String、1行に 1つの required_entity-specification（空の行は無視されます）

required_entity の詳細は、BuildingPackages を参照

目的: このパッケージが競合するもの（他のパッケージ、コマンド、ライブラリなど）のリストを定義します。

必須: いいえ

ディフォルト: ""

BuildingPackages

COPYRIGHT

タイプ: Multiline-文字列、1行に 1つの著作権、それぞれ 1年で始まります（空の行は無視されます）。

目的: このポートの著作権を指定します。

必須: はい

ディフォルト: ""

DESCRIPTION

タイプ: Multiline-String（最初と最後の空の行は無視されます。「\」を使用して行を折り返します）。

目的: ポートの詳細な説明を提供します。ポートが複数のパッケージを提供する場合、通常、それらは説明を共有します。

必須: はい

デフォルト: なし

FRESHENS

タイプ: Multiline-String、1行に1つのrequired_entity-specification（空の行は無視されます）

required_entity の詳細は、BuildingPackages を参照

目的: このパッケージが、指定されたパッケージ、コマンドなどの1つまたは複数のファイルを更新（オーバーライド）することを指定します。

必須: いいえ

ディフォルト: ""

GLOBAL_WRITABLE_FILES

タイプ: Multiline-String、1行に1つのglobal_writable_file_info-specification（空の行は無視されます）

global_writable_file_info の詳細は、BuildingPackages を参照

目的: 1つ以上のグローバルな書き込み可能なファイルまたはディレクトリを定義します。

これらは、パッケージによって提供されるプログラムの実行時に書き込まれることが期待されます。これは、たとえば、設定ファイルまたはキャッシュファイルのディレクトリにすることができます。

必須: いいえ

ディフォルト: ""

LICENSE

タイプ: Multiline-文字列、1行に1つのライセンス（空の行は無視されます）

目的: ポートに適用可能なライセンスを定義します。

必須: はい

デフォルト: なし

ライセンスは、/system/data/licenses のリストから選択するか、パッケージ内に含めるためのテキストファイルとして licenses フォルダのレシピの横に提供する必要があります。可能であれば、http://spdx.org/licenses/ の名前を使用してください。

追記: Haiku に含まれている有効なライセンスファイル名は次のとおりです:

Anti-Grain Geometry、Apache v2、Apache v2 with LLVM Exception、Artistic、
Artistic v2.0、BSD (2-clause)、BSD (3-clause)、BSD (4-clause)、
Be Sample Code License、Berkeley、Bitstream Charter、CDDL v1、CMake、
CQuantizer、Curl、DEC、FDL、Flex、Flite、Fraunhofer FDK AAC Codec、
FreeType、GNU GPL font exception、GNU GPL v1、GNU GPL v2、
GNU GPL v2 classpath exception、GNU GPL v3、GNU LGPL v2、
GNU LGPL v2.1、GNU LGPL v3、ICU、IJG、ISC、Info-ZIP、
Intel (2xxx firmware)、Intel (ACPICA)、Intel WiFi Firmware、
Jam、JasPer v2、LibJPEG、LibPNG、MAPM、MIT、MIT (no promotion)、
MPL v1.1、MPL v2.0、Marvell (firmware)、OpenGroup、OpenSSH、OpenSSL、
PCRE、Public Domain、Python、Ralink WiFi Firmware、
Realtek WiFi Firmware、SGI Free B、SIL Open Font License v1.1、
SQLite、Speex、WavPack、WebKit Apple、Zlib、bzip2

→この文字列から選ばないと（余計な文字を付加しても）、警告されます。

PACKAGE_GROUPS

タイプ: Multiline-String、1行に 1つのグループ。

目的: パッケージに必要な1つ以上のUnix グループを定義します。これらのグループは、パッケージのインストール時に作成されます。

必須: いいえ

ディフォルト: ""

PACKAGE_USERS

タイプ: Multiline-String、1行に 1つのユーザー指定（空の行は無視されます）。ユーザーの詳細については、BuildingPackages を参照してください。

目的: パッケージに必要な1人以上のUnixユーザーを定義します。これらのユーザーは、パッケージのインストール時に作成されます。

必須: いいえ

ディフォルト: ""

POST_INSTALL_SCRIPTS

タイプ: Multiline-String、1行に1つのプレフィックス相対ファイルパス（空の行は無視されます）。

目的: パッケージのインストール（または更新）時に実行されるシェルスクリプトを指定します。たとえば、ホスト固有のデータ（SSH ホストキーなど）を生成します。

必須: いいえ

ディフォルト: ""

PROVIDES

タイプ: Multiline-String、1行に1つのエンティティ仕様（空の行は無視されます）

エンティティの詳細は、BuildingPackages を参照

目的: このパッケージが提供するコマンド、ライブラリ、開発ライブラリ、仮想エンティティなどのセットを定義します。

これらの中で、すべてのパッケージはそれ自体を提供します（つまり、PROVIDES にはパッケージ名と一致するエンティティが含まれている必要があります。

必須: はい

デフォルト: なし

REPLACES

タイプ: Multiline-String、1行に 1つの required_entity-specification（空の行は無視されます）

required_entity の詳細は、BuildingPackages を参照

目的: このパッケージが置き換えるコマンド、ライブラリ、パッケージなどのセットを定義します。

これは、たとえば、パッケージが分割された場合に役立ちます。これは、分割されたパッケージではなく、どのパッケージをインストールする必要があるかをパッケージマネージャーに伝えることができるためです。

必須: いいえ

ディフォルト: ""

REQUIRES

タイプ: Multiline-String、1行に 1つのrequired_entity-specification（空の行は無視されます）

required_entity の詳細は、BuildingPackages を参照

目的: パッケージ化されたソフトウェアが実行時に必要とするコマンド、ライブラリ、パッケージ、仮想エンティティなどのセットを定義します。パッケージは、すべての要件が満たされている場合にのみインストールできます。

必須: いいえ

ディフォルト: ""

SUMMARY

タイプ: 文字列、1行、できれば 70文字を超えない長さ。

目的: このパッケージの正確な目的を示します。一般的なタイプの複数のパッケージを提供するポートの場合、これらの各パッケージには、（わずかに）異なる要約があり、それ自体が提供しているものを正確に表現する必要があります。

一般的でないすべてのパッケージタイプの場合、HaikuPorter は継承されたサマリーにサフィックスを自動的に追加します。

debug: サフィックス「(debug info)」（デバッグ情報）は、継承されたデバッグパッケージの要約に追加されます。

devel: サフィックス「 (development files)」（開発ファイル）は、継承された開発パッケージの要約に追加されます。

doc: サフィックス「(documentation)」（ドキュメント）は、継承されたドキュメントパッケージの概要に追加されます。

source: サフィックス「(source files)」（ソースファイル）は、継承されたソースパッケージの要約に追加されます。

必須: はい

デフォルト: なし

SUPPLEMENTS

タイプ: Multiline-String、1行に 1つの required_entity-specification（空の行は無視されます）

required_entity の詳細は、BuildingPackages を参照

目的: このパッケージが補足するコマンド、ライブラリ、パッケージなどのセットを定義します。

これは、たとえば、ライブラリポートがそのライブラリのPythonバインディングのみを含む兄弟パッケージを提供する場合に役立ちます。

この兄弟パッケージは、Python がすでにインストールされている場合に、基本パッケージと一緒にインストールするために自動的に選択されるように、SUPPLEMENTS=python を指定できます。

必須: いいえ

ディフォルト: ""

USER_SETTINGS_FILES

タイプ: Multiline-String、1行に 1つの user_settings_file_info-specification（空の行は無視されます）

user_settings_file_info の詳細は、BuildingPackages を参照

目的: パッケージソフトウェアで使用される1つ以上のユーザー設定ファイルまたはディレクトリを定義します。

必須: いいえ

ディフォルト: ""

--- - --- - --- - --- - --- - --- - --- - --- - --- - --- - --- - ----- ----- --

6-4. 参考: 出力のシェル関数の一覧:

次のシェル関数は、対応するビルドステージを実行するために HaikuPorter によって呼び出されます。

レシピがこれらの関数の1つの定義を提供しない場合、対応するビルドステージは空になります。つまり、何も起こりません。

PATCH()

目的: ポートのソースにアルゴリズムパッチを適用します。

通常、ソースにはパッチセットを提供することでパッチが適用されますが、プログラムでパッチを適用する方が便利な場合もあります。これは、この関数で実行できます。

一般的な例:

PATCH()
{
    find . -name '*.py' -exec sed -i -e 's|/usr/bin/env|/bin/env|g' {} \;
}

BUILD()

目的: 現在のポートのビルドステージを実行します。

autotools に基づくポートの場合、これには通常、configure と make の呼び出しが含まれます。

一般的な例:

BUILD()
{
    libtoolize --force --copy --install
    runConfigure ./configure
    make $jobArgs
}

INSTALL()

目的: ビルド結果を /packages ディレクトリの 1つ以上のサブフォルダーに収集します（結果のパッケージごとに 1つ）。

一般的な例:

INSTALL()
{
    make install
    strip $binDir/*
}

TEST()

目的: ビルド結果に対してテストを実行します。

一般的な例:

TEST()
{
    make check
}

--- - --- - --- - --- - --- - --- - --- - --- - --- - --- - --- - ----- ----- ---

6-5. 参考: レシピの使用例:

(1). 簡単なレシピの例（ DESCRIPTION に古いスタイルを使用）:

これは gawk のビルドレシピであり、かなり一般的です。

2つのコマンド（一方は他方へのシンボリックリンク）を提供し、実行にはHaiku が必要です。

SUMMARY="A pattern scanning and processing language"
DESCRIPTION="
    If you are like many computer users, you would frequently like to make
    changes in various text files wherever certain patterns appear, or
    extract data from parts of certain lines while discarding the rest. To
    write a program to do this in a language such as C or Pascal is a
    time-consuming inconvenience that may take many lines of code. The job
    is easy with awk, especially the GNU implementation: gawk.

    The awk utility interprets a special-purpose programming language that
    makes it possible to handle simple data-reformatting jobs with just a
    few lines of code.
    "
HOMEPAGE="http://www.gnu.org/software/coreutils"
SOURCE_URI="http://ftp.gnu.org/gnu/gawk/gawk-3.1.8.tar.bz2"
CHECKSUM_SHA256="5dbc7b2c4c328711337c2aacd09a122c7313122262e3ff034590f014067412b4"
LICENSE="GNU GPL v3"
COPYRIGHT="1983-2010 Free Software Foundation, Inc."
REVISION="2"
ARCHITECTURES="x86_gcc2 ?x86"

PROVIDES="
    gawk = $portVersion compat >= 3
    cmd:awk = $portVersion compat >= 3
    cmd:gawk = $portVersion compat >= 3
    "
REQUIRES="
    haiku
    "
BUILD_REQUIRES="
    "
BUILD_PREREQUIRES="
    haiku_devel
    cmd:gcc
    cmd:ld
    cmd:libtoolize
    cmd:make
    cmd:sed
    "

SOURCE_DIR="$portVersionedName"

BUILD()
{
    libtoolize --force --copy --install
    ./configure $configureDirArgs
    make
}

INSTALL()
{
    make install
}

TEST()
{
    make check
}

(2). 簡単なレシピの例（ DESCRIPTION に推奨されるスタイルを使用）

SUMMARY="Prints out location of specified executables that are in your PATH"
DESCRIPTION="GNU 'which' is an utility that is used to find which executable \
(or alias or shell function) is executed when entered on the shell prompt."
HOMEPAGE="http://carlo17.home.xs4all.nl/which/"
COPYRIGHT="Free Software Foundation"
LICENSE="GNU GPL v2"
REVISION="4"
SOURCE_URI="https://ftp.gnu.org/gnu/which/which-$portVersion.tar.gz"
CHECKSUM_SHA256="f4a245b94124b377d8b49646bf421f9155d36aa7614b6ebf83705d3ffc76eaad"
PATCHES="which-$portVersion.patch"

ARCHITECTURES="x86_gcc2 x86 x86_64 arm"

PROVIDES="
    which = $portVersion
    cmd:which = $portVersion
    "
REQUIRES="
    haiku
    "

BUILD_REQUIRES="
    haiku_devel
    "
BUILD_PREREQUIRES="
    cmd:awk
    cmd:gcc
    cmd:grep
    cmd:make
    cmd:sed
    "

defineDebugInfoPackage which \
    $binDir/which

BUILD()
{
    runConfigure ./configure --disable-dependency-tracking
    make $jobArgs
}

INSTALL()
{
    make install
}

(3). 簡単なレシピの例（複数行の著作権に推奨されるスタイルを使用）

SUMMARY="POSIX-compliant implementation of /bin/sh"
DESCRIPTION="Dash is a POSIX-compliant implementation of /bin/sh that aims to \
be as small as possible. It does this without sacrificing speed where \
possible. In fact, it is significantly faster than bash (the GNU Bourne-Again \
Shell) for most tasks."
HOMEPAGE="http://gondor.apana.org/~herbert/dash/"
COPYRIGHT="1989-1994 The Regents of the University of California
    1997 Christos Zoulas
    1997-2005 Herbert Xu"
LICENSE="GNU GPL v3"
REVISION="3"
SOURCE_URI="http://gondor.apana.org/~herbert/dash/files/dash-$portVersion.tar.gz"
CHECKSUM_SHA256="ae89fa9f1145b7748cf0740e1df04cd52fdf8a285da4911dd0f04983efba4e39"

ARCHITECTURES="!x86_gcc2 x86 x86_64"

PROVIDES="
    dash = $portVersion
    cmd:dash = $portVersion
    "
REQUIRES="
    haiku
    lib:libncursesw
    lib:libreadline
    "

BUILD_REQUIRES="
    haiku_devel
    "
BUILD_PREREQUIRES="
    cmd:awk
    cmd:gcc
    cmd:make
    "

BUILD()
{
    runConfigure ./configure
    make $jobArgs LIBS=-lbsd
}

INSTALL()
{
    make install
}

(4). 高度なレシピの例（ DESCRIPTION に古いスタイルを使用）

これは git のビルドレシピであり、ビルド時と実行時の両方で他の多くのパッケージに依存します。

さらに、git は多くの一般的な兄弟パッケージを提供します。

SUMMARY="Fast, scalable, distributed revision control system"
DESCRIPTION="
    Git is a free and open source distributed version control system designed
    to handle everything from small to very large projects with speed and
    efficiency.

    Git is easy to learn and has a tiny footprint with lightning fast
    performance. It outclasses SCM tools like Subversion, CVS, Perforce,
    and ClearCase with features like cheap local branching, convenient
    staging areas, and multiple workflows.
    "
HOMEPAGE="http://git-scm.com/"
LICENSE="GNU GPL v2"
COPYRIGHT="2005-2012 Git Authors (see git web site for list)"

SOURCE_URI="http://git-core.googlecode.com/files/git-1.7.10.2.tar.gz"
CHECKSUM_SHA256="e9e50d0d382183a9327d39334eb65db92852208e1438aab2a9bf8d06ef17b653"
SOURCE_DIR="$portVersionedName"
PATCHES="git-1.7.10.2.patch"

SOURCE_URI_2="http://git-core.googlecode.com/files/git-manpages-1.7.10.2.tar.gz"
CHECKSUM_SHA256_2="c9340fad1f521f3782abca4839d66bfee237f3e931856413561cf1b55fc9d550"

SOURCE_URI_3="http://git-core.googlecode.com/files/git-htmldocs-1.7.10.2.tar.gz"
CHECKSUM_SHA256_3="7f5eb11cf3dd5abb4705fb91f52c78ff4265b2e2eb15948cef311b3e04896d1c"

REVISION="2"

ARCHITECTURES="x86_gcc2 ?x86"

PROVIDES="
    git = $portVersion compat >= 1.7
    cmd:git = $portVersion compat >= 1.7
    cmd:git_receive_pack = $portVersion compat >= 1.7
    cmd:git_shell = $portVersion compat >= 1.7
    cmd:git_upload_archive = $portVersion compat >= 1.7
    cmd:git_upload_pack = $portVersion compat >= 1.7
    "
PROVIDES_arch="
    git_arch = $portVersion compat >= 1.7
    cmd:git_archimport = $portVersion compat >= 1.7
    "
PROVIDES_cvs="
    git_cvs = $portVersion compat >= 1.7
    cmd:git_cvsserver = $portVersion compat >= 1.7
    "
PROVIDES_daemon="
    git_daemon = $portVersion compat >= 1.7
    cmd:git_daemon = $portVersion compat >= 1.7
    "
PROVIDES_email="
    git_email = $portVersion compat >= 1.7
    cmd:git_send_email = $portVersion compat >= 1.7
    "
PROVIDES_source="
    git_source = $portVersion compat >= 1.7
    "
PROVIDES_svn="
    git_svn = $portVersion compat >= 1.7
    cmd:git_svn = $portVersion compat >= 1.7
    "

REQUIRES="
    haiku
    curl
    expat
    man
    openssl
    perl
    python
    zlib
    cmd:nano
    "
REQUIRES_arch="
    haiku
    git == $portVersion
    "
REQUIRES_cvs="
    haiku
    git == $portVersion
    "
REQUIRES_daemon="
    haiku
    git == $portVersion
    "
REQUIRES_email="
    haiku
    git == $portVersion
    "
REQUIRES_svn="
    haiku
    git == $portVersion
    "

BUILD_REQUIRES="
    $REQUIRES
    cmd:gcc
    cmd:ld
    cmd:make
    cmd:sed
    cmd:tar
    "
BUILD_PREREQUIRES="
    haiku_devel
    "

BUILD()
{
    make
}

INSTALL()
{
    make strip
    make install

    # replace copies of git binaries with symlinks
    cd $prefix/bin
    for program in git*; do
        ln -sfn "../lib/git-core/$program" "$program"
    done

    # copy manpages
    mkdir -p $manDir
    cp -rd $sourceDir2/* $manDir/

    # copy html documentation
    htmlDir=$docDir/html
    mkdir -p $htmlDir
    cp -rd $sourceDir3/*.html $htmlDir/
    rm $htmlDir/git-gui.html

    # copy asciidoc documentation for which there isn't any corresponding html
    asciidocDir=$docDir/asciidoc
    mkdir -p $asciidocDir
    for f in $sourceDir3/*.txt; do
        html=$sourceDir3/$(basename $f .txt).html
        if ! [ -e $html ]; then
            cp -d $f $asciidocDir/
        fi
    done

    packageEntries arch \
        documentation/packages/git/html/git-archimport.html \
        documentation/man/man1/git-archimport.1 \
        lib/git-core/git-archimport

    packageEntries cvs \
        bin/git-cvsserver \
        documentation/packages/git/html/git-cvsexportcommit.html \
        documentation/packages/git/html/git-cvsimport.html \
        documentation/packages/git/html/git-cvsserver.html \
        documentation/man/man1/git-cvsexportcommit.1 \
        documentation/man/man1/git-cvsimport.1 \
        documentation/man/man1/git-cvsserver.1 \
        documentation/man/man7/gitcvs-migration.7 \
        lib/git-core/git-cvsexportcommit \
        lib/git-core/git-cvsimport \
        lib/git-core/git-cvsserver

    packageEntries daemon \
        documentation/packages/git/html/git-credential-cache--daemon.html \
        documentation/packages/git/html/git-credential-cache.html \
        documentation/packages/git/html/git-daemon.html \
        documentation/man/man1/git-credential-cache--daemon.1 \
        documentation/man/man1/git-credential-cache.1 \
        documentation/man/man1/git-daemon.1 \
        lib/git-core/git-credential-cache--daemon \
        lib/git-core/git-credential-cache \
        lib/git-core/git-daemon

    packageEntries email \
        documentation/packages/git/html/git-send-email.html \
        documentation/man/man1/git-send-email.1 \
        lib/git-core/git-send-email

    packageEntries svn \
        documentation/packages/git/html/git-svn.html \
        documentation/man/man1/git-svn.1 \
        lib/git-core/git-svn
}

--- - --- - --- - --- - --- - --- - --- - --- - --- - --- - --- - ----- ----- ----

7. 依存の書き方「Handling Requirements」を参照してみる:

「レシピファイル」の依存の記述についてが説明されています。簡潔に説明できてないのがつらいところ。

参考:

Handling Requirements

注意！：このページは、HaikuPorterの現状を反映していません。HaikuPorter とレシピが実際に以下の説明に従うようにするには、さらにいくつかの作業があります...

ビルドを実行するホストにインストールされているソフトウェアに、ビルドされたパッケージが依存してしまうことを回避するために、 HaikuPorter はchroot() された環境でビルドコマンドを実行します。

HaikuPorter がchroot を作成すると、さまざまなビルドフェーズを実行しているシェルスクリプトに必要なパッケージのみがchroot に入力されます。

ポートのビルドまたは実行に必要なその他のものは、各ポートの「レシピファイル」で詳細に宣言されている必要があります。

Provides （提供されるもの）の記述

各パッケージは、提供するものを記述する必要があります。

→これは、コマンド、ライブラリ、仮想エンティティなどですが、パッケージ名に一致するエンティティ（実存する概念）を含める必要があります（そのパッケージを表すエンティティを提供するため）。

「レシピファイル」の「PROVIDES」変数にプロビジョンを追加する必要があります。

Provides の記述の詳細は、「パッケージポリシーの提供セクション」(the provides section of the packaging policy) を参照。

Requires（依存）の記述

「レシピファイル」の「REQUIRES」変数にポートのランタイムの依存の記述を追加する必要があります。

→複数のパッケージを生成するポートの場合、それぞれのパッケージの「REQUIRES」変数で異なる記述のセットを指定する必要があります。

これらの記述は、パッケージソフトウェアによって実行されるコマンド（ただし、ポートの一部ではない）や、パッケージソフトウェアに必要な機能を実装する共有ランタイムライブラリを参照できます。

Build Requires（ビルド時の依存）の記述

ポートのビルド時の要件は、ビルドプロセスで使用され、実行時に影響を与えるすべての外部エンティティです。

特に、ポートのビルドプロセスで使用される各ライブラリは、ビルドに必要なものを表します。これらのライブラリのコードは実行時に使用されるためです。したがって、外部ライブラリを使用するポートは、それらの開発ライブラリのビルドが必要であることを記述する必要があります（共有か静的かに関係なく）。

ポートのビルド要件は、ビルドレシピの「BUILD_REQUIRES」変数に追加する必要があります（ここでも、パッケージごとに1つの変数が含まれる可能性があります）。

ポートがリンクされているライブラリは実行時に必要になる可能性が非常に高いため、「BUILD_REQUIRES」でポートが参照する各共有開発ライブラリには、「REQUIRES」でそれぞれの共有ランタイムライブラリへの対応する参照が必要です。

開発ライブラリとランタイムライブラリのこの概念的な分離は、実際には別々のパッケージ（通常は「base」パッケージと「devel」開発パッケージ）によって提供されているため、不変です。開発ライブラリがランタイムライブラリへの単なるシンボリックリンクであるという事実は、実装の詳細にすぎません。

注：ビルド中に使用されるコマンドは、ビルドに必要なものを表す場合もあります。これは、ビルドプロセスが特定のプログラム（例えば、git）のコマンドを分析し、ビルド中に収集された情報を使用して実行時にgit を呼び出すように調整する場合に当てはまります。もちろん、与えられた例では、git を「REQUIRES」に追加する必要があります。

Build Prerequires（ビルド時の前提条件）の記述

ビルド中に必要なだけで、実行時には効果がないポートのビルド時の要件を、「レシピファイル」の「BUILD_PREREQUIRES」変数に追加する必要があります。

これらの宣言は通常、ポートのビルドシステムで必要なコマンドを参照します（ほとんどの場合、「make」および「make install」の呼び出しが含まれます）。この典型的な例は、「gcc、binutils、autoconf、make」などの実際のビルドツールですが、「sed」や「grep」などの追加コマンドもよくあります。

「require」の記述は、構文に準拠する必要があります

「require」仕様のいずれかの個々のエントリは、次の構文に準拠する必要があります。

詳細は、.PackageInfo を参照

required_entity      ::= [type ":"] entity_name [ version_operator version_ref ]
type                    ::= "cmd" | "devel" | "lib" | ...
version_operator    ::= "<" | "<=" | "==" | "!=" | ">=" | ">"

注：上記以外のタイプもありますが、ここでは関係ありません。

コマンドの依存の記述

コマンドの依存の記述は、「cmd:」を使用して記述します。

例：

cmd:sed

または

cmd:git >= 1.7

コマンドの名前に含まれるダッシュ（ハイフン）「`-`」はすべてアンダースコア「`_`」に置き換えます:

コマンド i586-pc-haiku-gcc の記述:

cmd:i586_pc_haiku_gcc

ランタイムライブラリの依存の記述:

ランタイムライブラリの依存の記述は、「lib:<library-basename>」を使用して宣言できます。

例：

lib:libz

または

lib:libpng >= 1.4

ライブラリのベース名は、ライブラリ名の後ろの最初のドット「.」のところまですべて含めます。これは、共有ライブラリと静的ライブラリの間に違いがないことを意味します。

コマンドと同様に、ライブラリの名前に含まれるダッシュ（ハイフン）「`-`」はすべてアンダースコア「`_`」に置き換えます。

パッケージの依存の記述:

「type」指定のない必須エンティティ（openssl など）は、パッケージになります。

直接、パッケージの依存の記述をするのは、パッケージの内容に依存するので、お勧めできません。

パッケージの名前が変更されたり分割されたりしているような依存の記述は誤っています。

宣言された実際の要件

HaikuPorter がポートのビルド結果をパッケージに収集する前に、宣言されたランタイムの依存の記述（REQUIRES）のセットが、ビルド時に使用された実際のバージョンに置き換えられます。

例：

openssl >= 1.0

上記を記述し、ビルド中に実際に「openssl-1.0.0j」を使用したポートの場合、HaikuPorter は、依存パッケージの「openssl >= 1.0.0j」をインストールします。

これは、「1.0.0j」未満の　openssl　のバージョンは、ポートに上位互換性があると予想されるため（古いバージョンの代わりに新しいバージョンを使用できるため）、正しく機能しない可能性があるためですが、必ずしもその逆ではありません。

詳細に記述してください！

一般に、依存の記述は、できるだけ詳細に記述することをお勧めします。

例えば、ポートに3つの異なる開発ライブラリが必要であり、それらはすべて同じ他のポートによって提供される場合でも、ビルドの必要に応じて、3つすべてを個別に宣言する必要があります。

それが行われなかった場合、必要なポートで単純なパッケージ分割を行うと、それらのライブラリを使用してポートのビルドを行うと失敗します。

「レシピファイル」の依存の記述の詳細さと、パッケージリポジトリ全体の堅牢性の間には直接的な関係があるため、詳細に記述してください。

--- - --- - --- - --- - --- - --- - --- - --- - --- - --- - --- - ----- ----- -----

8. 「HaikuPorter ガイドライン」(HaikuPorter Guidelines) を参照してみる:

「レシピファイル」を書くときの、アドバイスが書かれています。なので、重複は多めですが、いくつかを補完してくれます。

参考:

HaikuPorter-Guidelines

1). ポートのカテゴリ分け

HaikuPorts のポートのカテゴリ分けは、Gentoo Portage で使用されているポートのカテゴリ分けを反映しています。

HaikuPorts　に新しいポートを追加するときは、Gentoo Portage　で使用された一致する親ディレクトリの下に新しいポートを作成してください

Search Portage & Overlays :検索サイトにてGentoo Portage とそのオーバーレイでパッケージを検索できます

そこにない場合は、最適なものを見つけてください。

これにはいくつかの例外があります

それらの1つは「Qt」であり、Gentoo はこれを「qtcore」とラベル付けしています。

→Haiku のパッケージにはすべてのQt モジュールが含まれていますが、Gentoo には実際には「QtCore」モジュールしかありません。

HaikuPort のQt は、代わりに「libqt4」と呼ばれます。

2). 一般的なヒント

すべてのレシピは、100文字の行規則に従う必要があります。
「論理的な」改行はバックスラッシュ「\」でエスケープしてください。
唯一の例外は、チェックサムの「CHECKSUM_SHA256」とリンクの「SOURCE_URI」です。これらは行に分割できないためです。
レシピ名は小文字にする必要があり、パッケージ名にはダッシュ「-」を含めることはできませんが、代わりにアンダースコア「_」を使用してください。
レシピファイル名は、次の形式です:

package_name-vmajor.vmiddle.vminor.recipe

例:

cool_app-1.0.2.recipe

→パッケージ名とバージョン番号との区切りに「-」が使われます。

3). レシピファイル内の変数の正しい順序と間隔:

SUMMARY
DESCRIPTION
HOMEPAGE
COPYRIGHT
LICENSE
REVISION
srcGitRev
SOURCE_URI
CHECKSUM_SHA256
SOURCE_FILENAME
SOURCE_DIR
PATCHES
ADDITIONAL_FILES

ARCHITECTURES
SECONDARY_ARCHITECTURES
DISABLE_SOURCE_PACKAGE

commandSuffix
commandBinDir
relativeCommandBinDir

libVersion
libVersionCompat

GLOBAL_WRITABLE_FILES
USER_SETTINGS_FILES
POST_INSTALL_SCRIPTS
PACKAGE_USERS
PACKAGE_GROUPS

PROVIDES
REQUIRES
CONFLICTS
REPLACES
SUPPLEMENTS
FRESHENS

PROVIDES_devel
REQUIRES_devel

BUILD_REQUIRES
BUILD_PREREQUIRES

TEST_REQUIRES

defineDebugInfoPackage

PATCH()

BUILD()

INSTALL()

TEST()

→間隔（空行）まで指定されていたとは、知りませんでした。

4). 備考:

一部の変数はオプションです：

SOURCE_FILENAME、SOURCE_DIR、PATCHES、
ADDITIONAL_FILES SECONDARY_ARCHITECTURES、DISABLE_SOURCE_PACKAGE、
GLOBAL_WRITABLE_FILES、USER_SETTINGS_FILES、POST_INSTALL_SCRIPTS、
PACKAGE_USERS、PACKAGE_GROUPS、CONFLICTS、REPL

「defineDebugInfoPackage」マクロ行はオプションです。
PATCH()、BUILD()、TEST() 行はオプションです。
一部のユーザー変数はオプションであり、公式ではなく、レシピの外部では無視されます：

srcGitRev、commandSuffix、commandBinDir、
relativeCommandBinDir libVersion、libVersionCompat

PROVIDES、REQUIRES、CONFLICTS、REPLACES、SUPPLEMENTS、FRESHENS、BUILD_REQUIRES、BUILD_PREREQUIRES 行にあるパッケージ指定はアルファベット順に並べ替える必要があります（haiku または haiku_devel を最初に記述）

→パッケージ名を「アルファベット順に並べ替える」ことは知りませんでした。

5). 「Summary」行

Summary（概要）は、1行で長さが 70文字を超えないようにする必要があります。ピリオド「.」で終わらせるべきではありません。

「HaikuDepot」アプリでパッケージを選択するときに迷わないように、パッケージ名を記述すべきではありません。

ソフトウェアの開発に使用されたフレームワークまたは言語は、Summary には含めません。Haiku で実行されていることにも言及しません。

誤り:

SUMMARY="Paladin is an open source integrated development environment (IDE) for Haiku, written in C++ and Qt."

正解:

SUMMARY="An open source integrated development environment (IDE)"

6). 「Description」行

Description（説明）では、ライブラリまたはアプリケーションの機能をより詳細に説明する必要があります。少なくとも2〜3文の長さである必要があります。

Description の行の長さは 100文字を超えてはならず、パッケージマネージャーに表示されるテキストで、間違った場所での改行がないように、「\」文字で終了する必要があります。

Description のテキストはインデントしないでください。インデントするとテキストのレイアウトも崩れます。

誤り:

DESCRIPTION="
    C++ computer vision library with emphasize on customizable
    algorithms and data structures.
"

正解:

DESCRIPTION="VIGRA stands for \"Vision with Generic Algorithms\". It's an \
image processing and analysis library that puts its main emphasis on \
customizable algorithms and data structures. VIGRA is especially strong for \
multi-dimensional images, because many algorithms (e.g. filters, feature \
computation, superpixels) are implemented for arbitrary high dimensions. \
By using template techniques similar to those in the C++ Standard Template \
Library, you can easily adapt any VIGRA component to the needs of your \
application, without thereby giving up execution speed."

パッケージの公式ホームページにアクセスして、テキストをコピーして貼り付けてもかまいません。ただし、いくつかの点に注意してください。

主な機能をほんの一握り挙げてください。

説明が適切であることを確認してください。 Haikuで使用できない機能を削除します。

開発やライセンス変更などの履歴は記述しません。

ゲームの場合は、ゲームのプレイなどを説明してください。

また、ゲームのどこかでダウンロード/購入する必要があるデータ、またはゲームに最初に付属していたDVDでのみ入手可能なデータが必要な場合は、そのことを伝えてください。

最も重要なこと:

HaikuDepot の全文検索では、SUMMARY/DESCRIPTION で使用されている単語のみを見つけることができます。

7). 「HOMEPAGE」行

HOMEPAGE は有効なURL である必要があります。

多くのブラウザには、http://example.org/ などのURL の末尾のスラッシュを非表示にするデフォルト設定があります。

例えば、http://example.org

これは表示されているすべてのURL が有効であることを意味するものではありません。

有効なURL の例:

正解	誤り
`http://example.org/`	`http://example.org`
`https://www.libreoffice.org/`	`https://www.libreoffice.org`
`https://github.com/humdingerb/quicktour`	`https://github.com/humdingerb/quicktour/`
`https://github.com/HaikuArchives/DocumentViewer`	`https://github.com/HaikuArchives/DocumentViewer/`
`https://sourceforge.net/projects/launchpad/`	`https://sourceforge.net/projects/launchpad`
`https://www.gnu.org/software/hello/`	`https://www.gnu.org/software/hello`

→URL の末尾の「/」のあり・なしに注目

末尾にスラッシュを追加することは、一部のサイトでは正しいが、他のサイトでは間違っています。

ルールは次のとおりです:

空のパス（つまり、https://www.libreoffice.org/ のように「/」だけ）を持つURL は、スラッシュで終わる必要があります。
他のすべての場合、スラッシュ付きのURL にリダイレクトされない限り、URL はスラッシュで終わらないようにする必要があります。

レシピのホームページに複数のURLが必要な場合:

以下のスタイルを使用してこれを行うことができます。このスタイルでは、最初の行を除く各行の先頭にタブが挿入されます:

HOMEPAGE="http://miniupnp.free.fr/
    https://miniupnp.tuxfamily.org/"

8). 「Source URI」行

100文字の制限ルールはSOURCE_URI リンクとSOURCE_URI_n リンクには適用されませんが、可能な場合は短いURI を使用することをお勧めします。

例えば、sourceforge.net リンクはかなり長くなる可能性があるため、以下のリンク形式を提供します。

sourceforge のファイルダウンロード用の代替リンク形式:

https://downloads.sourceforge.net/<project-name>/<file-name>

→このURI を使用してアーカイブをダウンロードすることをお勧めします。これは、SourceForge が利用可能な最も近いミラーを選択し、サブディレクトリを自動的に検索して、正しいリダイレクトを送信できます。

9). 「SOURCE_FILENAME」行

ポリシーでは、すべての「アーカイブ名」を - の形式にする必要があるとしています。ほとんどのパッケージはそのように名前が付けられています。

そうでない場合は、「SOURCE_FILENAME」行を使用します。

10). 「SOURCE_DIR」行

解凍されたときのほとんどのソースは、 - という名前のディレクトリにあります。

これはHaikuPorter のデフォルト設定であり、移植するパッケージの場合は、ソースディレクトリを詳細に指定する必要はありません。

それ以外の場合は、「SOURCE_DIR」行を使用して、そこにディレクトリを指定する必要があります。

11). 「Patches」行

パッチは、プロジェクトがHaiku のコード提供を受け入れたくない、または受け入れることができない場合にのみ、長期的に活用する必要があります。できるだけ、アップストリーム（アプリの公式サイト）の変更を試してください。

12). $portName 変数

SOURCE_FILENAME、SOURCE_DIR、PATCHES などの行で「$portName」変数を使用する場合は注意が必要です。

「$portName」にはセカンダリアーキテクチャのサフィックスが含まれているため、ハイブリッドパッケージをビルドすると「_」になります。パッケージが SECONDARY_ARCHITECTURES を宣言していない場合、これは問題ではありません。

13). Tools パッケージ

「tiff」や「glew」などの一部のライブラリは、追加のツールを配布します。

これらのプログラムは、メインアーキテクチャ用にのみビルドして（パッケージ全体をセカンダリアーキテクチャ用にのみビルドできる場合を除く）、名前に「_tools」サフィックスが付いたパッケージで配布する必要があります。

14). Debuginfo パッケージ

すべてのパッケージでdebuginfo パッケージを定義する必要があります。

このように、ライブラリをダウンロードするときに、ユーザーは必要なデータのみをダウンロードします。

これは、「defineDebugInfoPackage」マクロを使用して実行できます:

例:

defineDebugInfoPackage protobuf$secondaryArchSuffix \
    "$binDir"/protobuf \
    "$libDir"/libprotobuf.so.7.1.0

15). Versions

レシピで宣言されたライブラリのバージョンは、so ファイルのバージョンと一致する必要があります。

例えば、パッケージが libtiff.so、libtiff.so.5、および libtiff.so.5.1.10 を提供する場合、対応するPROVIDES 行は次のようになります。

lib:libtiff = 5.1.10 compat >= 5

パッケージのメインバージョンが異なっていても。

16). Revisions

リビジョンは、同じバージョンの異なるソフトウェアパッケージを区別するために使用されます。

したがって、パッケージのリビジョンは、パッケージまたはその内容が変更された場合にのみ上げる必要があります。

例えば、変更されたPROVIDES セクションまたは異なるフラグでビルドされたバイナリ。

レシピが変更された場合は（例えば、新しいダウンロード場所が追加された場合は）、リビジョンを上げるべきではありませんが、結果のパッケージは同じです。

17). ディレクトリの作成

ディレクトリを作成するときは、常に「mkdir -p」を使用してください。

このやり方なら、ディレクトリがすでに存在する場合でもビルドは失敗しません。

18). commandBinDir ユーザー変数の使用

cmd: ランタイムを提供するレシピを x86_gcc2 プライマリアーキテクチャでビルドできない場合は、

commandSuffix（場合によっては）、commandBinDir、および relativeCommandBinDir（必要な場合）を次のように定義することをお勧めします。

commandSuffix=$secondaryArchSuffix
commandBinDir=$binDir
relativeCommandBinDir=$relativeBinDir
if [ "$targetArchitecture" = x86_gcc2 ]; then
    commandSuffix=
    commandBinDir=$prefix/bin
    relativeCommandBinDir=bin
fi

それで:

PROVIDES では、cmd: で始まるすべての行で、$secondaryArchSuffix を $commandSuffix に置き換える必要があります。

「defineDebugInfoPackage」マクロでは、$binDir が出現するたびに $commandBinDir に置き換える必要があります。

BUILD() では、「runConfigure ./configure」を「runConfigure --omit-dirs binDir ./configure --bindir="$commandBinDir"」に置き換える必要があります

必要に応じて、$relativeBinDir を $relativeCommandBinDir に置き換える必要があります。

備考:

commandSuffix および / または commandBinDir は、プライマリアーキテクチャ（x86_gcc2など）で壊れているとマークされているレシピにのみ使用する必要がありますが、セカンダリアーキテクチャ（x86など）で構築することもできます。

commandSuffix は、cmd: プライマリアーキテクチャ上に構築されていないレシピからランタイムをプルするための REQUIRES、BUILD_PREREQUIRES、または TEST_REQUIRES のエントリでも必要になる場合があります。

commandBinDir および / または relativeCommandBinDir は、不要な場合は省略できます。

レシピにライブラリが含まれていない場合は、commandSuffix を追加しないでください。

代わりに、「SECONDARY_ARCHITECTURES="x86"」行をtest 内に含める必要があります:

ARCHITECTURES="!x86_gcc2 ... "
if [ "$targetArchitecture" = x86_gcc2 ]; then
SECONDARY_ARCHITECTURES="x86"
fi

→もちろん、ARCHITECTURES の...は、レシピがうまくビルドされる主要なアーキテクチャのリストです。

19). libVersionCompat ユーザー変数の使用

レシピが共有ライブラリを提供する場合、次の例のように libVersion と libVersionCompat を定義すると便利です:

libVersion="5.1.10"
libVersionCompat="$libVersion compat >= ${libVersion%%.*}"

これにより、以下を置き換えることができます:

レシピファイルの PROVIDES および PROVIDES_devel の「$libVersionCompat」により「= 5.1.10 compat >= 5」
「defineDebugInfoPackage」マクロの「"$libDir"/libtiff.so.$libVersion」により「"$libDir"/libtiff.so.5.1.10」

20). ハイブリッド対応のレシピファイル

ビルドツール:

適切なアーキテクチャのハイブリッドパッケージをビルドする場合は、ビルドツールを使用する必要があります。これを実現するには、$secondaryArchSuffix　変数を使用します。異なるアーキテクチャのツールを混在させることはできません。

コンパイラ（gcc など）、リンカ（ld など）、config ツール（pkg_config、sdl_config など）をライブラリに使用する必要があります。これを忘れると、ライブラリの欠落または欠落したシンボルエラーが発生する可能性があります。

--- - --- - --- - --- - --- - --- - --- - --- - --- - --- - --- - ----- ----- ----- -

9. 「HaikuPorter を使用したパッチ適用」(Patching with HaikuPorterHaikuPorter) を参照してみる:

ビルドするためにソースプログラムにパッチを適用する必要がある場合は、パッチセットの作成について知っておく必要があります。

参考:

HaikuPorter を使用したパッチ適用

「cpio」パッケージを対象にしながら、パッチを作成するやり方を学べます。パッチセットの自動生成についても含まれていました。

教材のバージョンが上がっています。実際に検証していないので注意

教材のバージョンが上がって(cpio-2.13) 、記述と違いが出ています。学びづらいので、別の投稿で教材を変更して学ぶことにしました。

こちらは、大まかな翻訳をして、ほとんど検証していません。ただし、参考になります。

注意: 記述されているコマンドのパラメータの文字が一部抜けていました

こちらの記事では、修正しました:

> haikuporter --no-dependencies cpio

↓

> haikuporter --no-source-packages --get-dependencies cpio

記事をみると、ソースパッケージが生成されているので、もしかしたら、

> haikuporter --get-dependencies cpio

1). cpio にて、パッチセットを削除し、再作成

git clone でダウンロードしたports ツリーのルートにいると仮定します。

> cd app-arch/cpio
> mv patches/cpio-2.12.patchset patches/cpio-2.12.patchset.old
> lpe cpio-2.12.recipe

→「lpe」で端末から「Pe」が起動されます。 Pe で、「PATCHES=」行を削除し、保存して閉じます。

2). レシピの「BUILD_REQUIRES」で、「devel：libiconv」が必要です

これはインストールされない可能性が高いため、次のように実行します。

pkgman install -y devel:libiconv

→pkgman では、パッケージ指定で「開発パッケージ」であることを指定できるようです

3). cpio のパッケージ化を試して、何が起こるかを確認:

> haikuporter --no-source-packages --get-dependencies cpio
# eventually, we'll run into an issue!
/sources/cpio-2.12/src/makepath.c: In function `make_path':
/sources/cpio-2.12/src/makepath.c:72: parse error before `char'
/sources/cpio-2.12/src/makepath.c:73: `slash' undeclared (first use in this function)
/sources/cpio-2.12/src/makepath.c:73: (Each undeclared identifier is reported only once
/sources/cpio-2.12/src/makepath.c:73: for each function it appears in.)
# some more error output
keeping chroot folder /path/to/ports/tree/app-arch/cpio/work-2.12 intact for inspection

→このエラーは、gcc2 が非常に古いため、gcc2 でビルドするときによく発生します。

この問題は、gcc2 が変数宣言が関数またはブロック（if ステートメントなど）の先頭にあることを想定していることです。これは、新しいバージョンのgcc ではエラーしません。

4). 修正は、makepath.c ファイルの編集:

(1). ファイルマネージャ (Tracher) のウィンドウを開きます:

> open work-2.12/sources/cpio-2.12/

(2). タブ補完を使用してソースフォルダにアクセス:

開いたウィンドウで、「src」を右クリック、「makepath.c」をクリック →Pe で開きます。

(3). エラーを見つけ、必要に応じて修正し、ファイルを保存、完了したら閉じます

5). 問題が解決したか確認:

> haikuporter --no-source-packages --get-dependencies cpio

make_path.c エラーを乗り越えましたが、新しい問題が発生...

../lib/libpax.a(rtapelib.o): In function `rmt_open__':
rtapelib.c:(.text+0x85c): undefined reference to `gethostbyname'
collect2: ld returned 1 exit status

6). リンカエラーに移る前に、

(1). ソースのトラッカーウィンドウを開いたままで、

　　Windows+ALT+T で新しいターミナルを開きます:

(2). 変更したmakepath.c ファイルを、追加、コミットします:

> git add src/makepath.c
> git commit -m  "Build fixes for gcc2."

→「-m "Build fixes for gcc2."」を付けないと、

コミットメッセージを追加するためのエディターが開きます。

メッセージ「例: "Build fixes for gcc2."」を追加し、保存して閉じます。

7). リンカーエラーは、Haiku のライブラリの名前がLinux や他のUNIX ライクとは異なるために発生:

Haiku では、gethostbyname はlibnetwork にありますが、他のUNIX ライクは通常libsocket にgethostbyname があります。

→修正するには、configure.ac を変更

検索するライブラリのリストを含むgethostbyname のチェックを追加します。

詳細は、古いパッチセットを参照してください

8). 再び、パッケージを作成:

> haikuporter --no-source-packages --get-dependencies cpio
grabbing cpio-2.12-1-x86_gcc2.hpkg ...

→今回は、ビルドが正常に終了

9). 最終的な変更をソースにコミット:

(1). 2番目のターミナルウィンドウに戻ります:

(2). 最終的な変更をソースにコミットします:

> git add configure.ac
> git commit

→メッセージを追加し保存して閉じます

メッセージ例： "Search for gethostbyname in libsocket and libnetwork."

和訳: 「libsocket とlibnetwork でgethostbyname を検索してください。」

(3). ターミナルを閉じます

10). 最初のウィンドウに戻って、以下を実行:

> haikuporter --no-source-packages --get-dependencies -e cpio
Extracting patchset for cpio-2.12.tar.gz

→和訳: cpio-2.12.tar.gz のパッチセットを抽出しています

> ls patches
cpio-2.12.patchset   cpio-2.12.patchset.old

→新しいパッチセットが出来ました！

→ソースを編集して「git add」と「git commit」しておけば、新しいパッチセットが自動作成できるみたい

11). パッチを有効にします：

> lpe cpio-2.12.recipe

次のように行を追加して、パッチを有効にします：

PATCHES="cpio-2.12.patchset"

→更新されたレシピを保存して閉じます

12). パッチが実際に機能することをテスト:

HaikuPorter でソースツリーを削除し、ビルドを最初から開始

> haikuporter --no-source-packages --get-dependencies --force cpio

プロセス全体が実行され、最初に、新しいパッチセットを適用したHaikuPorter の出力が表示

レシピが完成しました！

教材のバージョンが上がっています。実際に検証していないので注意

--- - --- - --- - --- - --- - --- - --- - --- - --- - --- - --- - ----- ----- ----- --

10. Haiku が参考にした、gentoo Linux のパッケージ管理:

参考: ebuild ファイル（レシピファイル）の記述について

Haiku の「haikuports」が作られる時に参考としたのが、gentoo Linux のパッケージ管理の機能です。確認するとHaiku よりも複雑です。

Gentoo Ebuild 基本ガイド

ebuild ファイル（Haiku でのレシピファイル）はGentoo パッケージマネージャによって使用されるテキストファイルで、個々のソフトウェアパッケージを識別し、Gentoo パッケージマネージャがソフトウェアパッケージをどのように扱えばよいかを指示します。

Ebuild での依存の記述:

基本的な依存の書き方:

DEPEND="dev-lang/ruby
    dev-ruby/ruby-gtk2
    dev-ruby/mysql-ruby"

→カテゴリとパッケージ名で依存関係は指示されています。

特定のバージョンのパッケージが必要なときの書き方:

DEPEND=">=dev-libs/openssl-0.9.7d"

実際のebuild ファイルの記述を見るには

→サイトでのパッケージ検索時に、パッケージを選択してから、バージョン番号をクリックすると、ファイルの内容を確認できました。

実際のGentoo リポジトリの場所は、repos.conf ファイルによって指示され、通常は /var/db/repos/gentoo です。

ebuild は、例えば /var/db/repos/larry のようなカスタムリポジトリに置くことが推奨されています。

--- - --- - --- - --- - --- - --- - --- - --- - --- - --- - --- - ----- ----- ----- ---

11. haikuporter のヘルプ表示（和訳）:

> cd ~/Git/haikuporter/
> haikuporter --version
haikuporter 1.2.7

> haikuporter -h

和訳:

Usage: haikuporter [options] portname[-portversion]

---
Options:
  --version             プログラムのバージョン番号を表示して終了
  -h, --help            このヘルプメッセージを表示して終了

---
  Basic Actions:
    ベーシックはアクションを描写しません

    -l, --list          使用可能なポートの一覧表示
    --list-packages     利用可能なパッケージの一覧表示
    -a, --about         指定されたポートの説明を表示
    -s, --search        ポートを検索（正規表現）
    --search-packages   パッケージを検索（正規表現）
    -E, --enter-chroot
                        chroot()-environment と入力するだけで、ビルドしません
    --do-bootstrap      循環依存のあるすべてのパッケージをビルドします
    -D, --analyze-dependencies
                        ポート間の依存関係を分析して表示
                        情報; ポートパラメータは必要ありません
    -c, --clean         指定されたポートの作業ディレクトリをクリーンアップします
    --purge             作業ディレクトリをクリーンアップし、指定されたポートのダウンロードを削除します
    -g, --get           ポートツリーを取得/更新します
    -t, --tree          haikuportsソースツリーの場所を表示
    --lint              ポートツリーをスキャンして問題を探します。ポート名がなければ、パッケージ名順に表示
    --list-dependencies
                        ポートの依存関係を一覧表示
    --build-master      ビルドマスターとして実行し、ビルドをビルダーに委任します

---
  Basic Options:
    haikuporter 機能の基本的な変更

    -o, --location      レシピの場所を表示（スクリプト編集の場合は検索を使用）
    -q, --quiet         ビルドアクションからの出力を抑制します
    -v, --verbose       レシピが壊れている理由を表示
    -y, --yes           すべての質問に「はい」と答えます
    -j JOBS, --jobs=JOBS
                        構築する同時ジョブの数
    -S, --strict-policy
                        厳格なパッケージポリシーの順守が必要。ポリシー違反があるとパッケージングは失敗します
    --debug             致命的なエラーのPythonスタックトレースを表示
    -n, --nopatch       ソースにパッチを適用せず、ダウンロードして解凍するだけです
    -e, --extract-patchset
                        ポートソースから現在のパッチセットを抽出します
    -G, --no-git-repo   ポートソースのgit-repo を作成しません
    -B, --patch-files-only
                        ポートをビルドせず、パッチファイルをダウンロード、解凍、適用するだけです
                        ただし、PATCH() は呼び出しません
    -b, --nobuild       ポートをビルドせず、ダウンロード、解凍、パッチを適用するだけです
    -p, --nopackage     パッケージを作成せず、ビルド後に停止します
    --all-dependencies  指定されたポートの古い依存関係をすべて構築します
    --get-dependencies  必要なすべての依存関係をインストールしてから、ポートをビルドします
    --update-dependencies
                        必要な依存関係をビルドまたは更新し（hpkgで停止）、ポートをビルドします
    --missing-dependencies
                        欠落している直接および間接の依存関係をビルドしてから、ポートをビルドします
    --no-source-packages
                        ソースパッケージを作成しません
    --test              結果のバイナリでテストを実行します
    -C, --nochroot
                        chroot() なしでビルド-環境-ビルド/インストールプロセスをデバッグするためのもの
    -f, --force         手順（解凍、パッチの適用、ビルド）を強制的に実行します
    -F, --preserve-flags
                        変更されたレシピファイルが検出されたときにフラグをクリアしません
    -P PORTSFILE, --portsfile=PORTSFILE
                        指定されたファイル内のすべてのポートを処理します
    --create-source-packages
                        （通常の）ソースパッケージのみをビルドします
    --create-source-packages-for-bootstrap
                        ブートストラップイメージで必要なソースパッケージのみをビルドします
    -w WHY, --why=WHY
                        ビルドするポートの依存関係として、指定されたポートがプルインされる理由を判別します
    --config=CONFIGFILE
                        グローバル構成ファイルの場所を指定します
                        デフォルトは「~/config/settings/haikuports.conf」です
    --print-raw
                        スクリプトで使用するためのプリンターで読み取り可能な出力
    --print-filenames
                        パッケージリストと検索でパッケージ名の代わりにファイル名を出力
    --ignore-messages   レシピ内のメッセージを無視します

---
  Advanced Options:
    haikuporter 機能の高度な変更

    --cross-devel-package=CROSSDEVELPACKAGE
                        クロス開発パッケージ（実際の「sysroot」パッケージ）へのパス
                        デフォルト（クロスビルディングの場合）は、ターゲットアーキテクチャに
                        一致する「/boot/system/development/cross」にあるものです。
    --secondary-cross-devel-packages=SECONDARYCROSSDEVELPACKAGES
                        セカンダリクロス開発パッケージ（実際の「sysroot」パッケージ）へのパスのコンマ区切りリスト。
                        構成されたセカンダリターゲットアーキテクチャごとに1つのパスを指定する必要があります
                        （同じ順序で指定）

    --licenses=LICENSESDIRECTORY
                        既知のライセンスを含むディレクトリへのパス。 デフォルトは「<systemDir>/data/licenses」
    --system-mimedb=SYSTEMMIMEDB
                        システムMIMEDB を含むディレクトリへのパス。 デフォルトは「<systemDir>/data/mime_db」
    --command-mimeset=COMMANDMIMESET
                        「mimeset」コマンドを指定します。 デフォルトは「mimeset」
    --command-package=COMMANDPACKAGE
                        「package」コマンドを指定します。 デフォルトは「package」
    --command-package-repo=COMMANDPACKAGEREPO
                        「package_repo」コマンドを指定します。 デフォルトは「package_repo」
    --cross-tools=CROSSTOOLS
                        Haiku ビルドシステムのconfigure スクリプトによって作成されたcross-tools ディレクトリへのパスを指定します
    --sourceforge-mirror=SOURCEFORGEMIRROR
                        sourceforge に使用されるミラー
    --no-system-packages
                        依存関係を解決するためにシステムパッケージを使用しません
    --repository-update
                        リポジトリ内の依存関係情報を更新します
    --check-repository-consistency
                        リポジトリの整合性を確認します 
    --no-repository-update
                        リポジトリ内の依存関係情報を更新しないでください 
    --no-package-obsoletion
                        廃止されたパッケージをパッケージディレクトリから移動しません 
    --prune-package-repository
                        パッケージリポジトリを整理します
    --create-package-repository=CREATEPACKAGEREPOSITORY
                        指定された出力パスにパッケージリポジトリを作成します
    --sign-package-repository-privkey-file=PACKAGEREPOSITORYSIGNPRIVATEKEYFILE
                        指定されたminisign 秘密鍵ファイルを使用してパッケージリポジトリに署名します
    --sign-package-repository-privkey-pass=PACKAGEREPOSITORYSIGNPRIVATEKEYPASS
                        指定されたミニサインパスワードでパッケージリポジトリに署名します 
    --check-package-repository-consistency
                        すべてのパッケージを依存関係で解決することにより、パッケージリポジトリの整合性をチェックします
    --literal-search-strings
                        検索文字列を式ではなくリテラルとして扱います
    --ports-for-files   提供されたファイルのリストの影響を受けるすべてのポートを一覧表示します
    --ports-for-packages
                        パッケージの一覧表示。提供されたポートを一覧表示します
    --active-versions-only
                        すべてのポートではなく、アクティブなバージョンのポートのみをチェックインします
    --check-ports-releases
                        アップストリームで公開されたポートの新しいリリースを確認します

---
  Build Master Options:
    ビルドマスターモードで実行されているHaikuporterにのみ関連するオプション

    --system-packages-directory=SYSTEMPACKAGESDIRECTORY
                        システムパッケージの検索に使用するディレクトリを指定します
    --build-master-output-dir=BUILDMASTEROUTPUTDIR
                        ビルドマスター出力を書き込む場所を指定します
    --local-builders=LOCALBUILDERS
                        ローカルビルダーの数（ネイティブHaiku のみ）
    --console           ビルドマスターの仮想コンソールを表示

--- - --- - --- - --- - --- - --- - --- - --- - --- - --- - --- - ----- ----- ----- ----

12. 追記: HaikuPorter の 2番目のバージョンについての説明:

今更ですが、このような情報がヒットしました。たぶん、重複しているところが多いと思われます。追加情報と思えばいいのかな。

HaikuPorterForPM を参照:

→Haiku 用のパッケージをビルドすることを目的とした「HaikuPorter」の 2番目のバージョンについての説明です。

抜粋:

HaikuPorter は、HaikuPort にポートごとに置かれた「レシピファイル」の指示により、ビルドする、コマンドラインの Python アプリケーションです。

1). HaikuPorter の処理:

1つ以上の元のソースコードのアーカイブを読み込み

アーカイブを解凍

Haiku で動くように、ソースにパッチを適用

ポートのビルドに必要なパッケージのみを含む chroot() 環境でソフトウェアをビルド

配布用に1つ以上のパッケージ（*.hpkg）を生成

2). HaikuPorter は、

レシピファイルで宣言されている他のHaikuPort への依存関係を自動的に解決できます。

必要なパッケージのいずれかが欠落している場合は、それらのパッケージを生成するポートが最初に構築されます。

→上記の話は、「ちゃんとレシピファイルに依存が書かれていれば」の話です。それほど親切なツールではありません。結局はレシピファイルの記述しだいです。依存するパッケージとそのバージョンを見つけて、どう記述するかが求められます。

3). HaikuPorter 自体には 2つのものが必要です:

(1). HaikuPorts.conf

→グローバルなHaikuPorter オプションが含まれています

(2). ports ツリー

→ビルドするすべてのポートのレシピファイルが含まれています

4). レシピファイルを作成する

「レシピファイル」は、ポート（パッケージ）の特定のバージョンについて、そのポート用にビルドされるパッケージを指定し、ビルドに必要な（依存も含めた）すべての情報を記述することが必要です。

「レシピファイル」の詳細は、下記を参照:

(1). HaikuPorter-BuildRecipes

和訳はこちら → 6.「HaikuPorter-BuildRecipes wiki」

(2). HaikuPorter-Guidelines

和訳はこちら → 8. 「HaikuPorter ガイドライン」(HaikuPorter Guidelines): レシピの書き方の補完

5). ポートとパッケージ

(1). 各ポートは一連のパッケージを生成します:

通常は、ポートのメインのバイナリ/ライブラリに加えて、ソースとデバッグパッケージを含む基本パッケージです:

sed-4.4-4-x86_64.hpkg 　　　　　 ←（アプリのパッケージ）

sed_debuginfo-4.4-4-x86_64.hpkg 　←（defineDebugInfo パッケージ）

sed_source-4.4-4-x86_64.hpkg 　　←（source パッケージ）

→レシピファイルにdefineDebugInfo パッケージの記述を追加しておくことと、haikuporter に与えるコマンドで生成されるパッケージが変わります。

ライブラリを提供するポートは通常、追加の開発パッケージも提供します:

zlib-1.2.11-4-x86_64.hpkg 　　　　　←（ライブラリのパッケージ）

zlib_devel-1.2.11-4-x86_64.hpkg 　　←（ライブラリの開発パッケージ）

→レシピファイルに開発パッケージの記述を追加しておくことと、haikuporter に与えるコマンドで生成されるパッケージが変わります。

(2). HaikuPorter によってビルドされたすべてのパッケージは、ports ツリーの「packages」フォルダに置かれます:

hp qpdfview を実行した場合:

/boot/home/Git/haikuports/packages/qpdfview-0.4.18-6-x86_64.hpkg

→hp コマンドを使うと（ソースパッケージの生成は抑止されており、qpdfview-0.4.18 レシピ内にはdefineDebugInfo パッケージの記述がないので、）通常のパッケージのみ生成されます。

(3). 「.hpkg」ファイルは（tar またはzip ファイルと同じように）アーカイブファイルです

さらに、ファイルの別のセクションにパッケージメタ情報が含まれています

「.hpkg」ファイルを作成すると、メタ情報は「.PackageInfo」ファイルを介して提供されます。便宜上、ファイル自体が追加されます。アーカイブにも保存され、後で抽出できますが、packagefs によって無視されます。

(4). 「.PackageInfo」ファイルについて

パッケージ化を実行して「.hpkg」ファイルを作成するときに必要となるパッケージの情報ファイルです。画面を見ていると、パッケージ化の完了直前にメッセージとして内容が表示されています。

出来た「.hpkg」ファイルを展開することで、内容を確認できます:

「.hpkg」ファイルをコピー:

> ls -1a ~/My/Downloads/
.
..
qpdfview-0.4.18-6-x86_64.hpkg

「.hpkg」ファイルを展開:

> ls -1a ~/My/Downloads/
.
..
.PackageInfo 　←（パッケージの自動マウント時は無視されます）
apps
data
documentation
qpdfview-0.4.18-6-x86_64.hpkg

内容を確認:

> cat ~/My/Downloads/.PackageInfo

name                    qpdfview
version                 0.4.18-6
architecture            x86_64
summary                 "A tabbed document viewer"
description             "qPDFView is a tabbed document viewer using Poppler, libspectre, DjVuLibre, CUPS and Qt, licensed under GPL version 2 or later."
packager                "FuRuYa7 <mymail@mydomain.org>"
vendor                  "Haiku Project"
licenses {
        "GNU GPL v2"
}
copyrights {
        "Adam Reichold et al."
}
provides {
        qpdfview = 0.4.18
        app:qpdfview = 0.4.18
}
requires {
        haiku >= r1~beta3_hrev55897-1　←（実行に必要なパッケージ）
        lib:libdjvulibre >= 21.6.0
        lib:libgl >= 1.0.0
        lib:libmagic >= 1.0.0
        lib:libpoppler >= 117.0.0
        lib:libpoppler_qt5 >= 1.30.0
        lib:libqt5concurrent >= 5.15.2
        lib:libqt5core >= 5.15.2
        lib:libqt5gui >= 5.15.2
        lib:libqt5printsupport >= 5.15.2
        lib:libqt5sql >= 5.15.2
        lib:libqt5svg >= 5.15.2
        lib:libqt5widgets >= 5.15.2
}
urls {
        "https://launchpad.net/qpdfview/"
}
source-urls {
# Download
        "https://launchpad.net/qpdfview//trunk/0.4.18/+download/qpdfview-0.4.18.tar.gz"
# Location 2
        "https://ports-mirror.haiku-os.org/qpdfview/qpdfview-0.4.18.tar.gz"
}

→依存パッケージは、実行に必要なパッケージのみが記述されています。

6). リポジトリ

(1). ポートごとに、最新バージョンがアクティブバージョンと見なされます:

> ls -1 /boot/home/Git/haikuports/sys-apps/sed/*.recipe
:
/boot/home/Git/haikuports/sys-apps/sed/sed-4.2.1.recipe
/boot/home/Git/haikuports/sys-apps/sed/sed-4.4.recipe
/boot/home/Git/haikuports/sys-apps/sed/sed-4.8.recipe 　　←（注目）

→最新バージョンがデフォルトです。

なので、下記はどちらも「sed-4.8.recipe」を使ったパッケージ化が実行されます。

hp sed

hp sed-4.8

(2). ポートツリーの「リポジトリ」フォルダに、ビルドされるパッケージを表す「.DependencyInfo」ファイルが配置されます。

> ls -1 /boot/home/Git/haikuports/repository/ | grep ^qpdfview
:
qpdfview-0.4.18.DependencyInfo　　　　　　←（注目）

(3). ポート間の依存関係の解決では、このアクティブなパッケージ情報のセットのみが考慮されます。

> cat /boot/home/Git/haikuports/repository/qpdfview-0.4.18.DependencyInfo

{
    "architecture" : "x86_64",
    "buildPrerequires" : [
        "cmd:gcc",　　　　　　←（ビルドに必要なコマンド類）
        "cmd:lrelease >= 5",
        "cmd:make",
        "cmd:pkg_config",
        "cmd:qmake >= 5"
    ],
    "buildRequires" : [
        "haiku_devel",　　　　　　←（ビルドに必要なパッケージ）
        "devel:libdjvulibre",
        "devel:libgl",
        "devel:libmagic",
        "devel:libpoppler >= 117",
        "devel:libpoppler_qt5",
        "devel:libqt5concurrent",
        "devel:libqt5core",
        "devel:libqt5gui",
        "devel:libqt5printsupport",
        "devel:libqt5sql",
        "devel:libqt5svg",
        "devel:libqt5widgets",
        "devel:libz"
    ],
    "name" : "qpdfview",
    "provides" : [
        "qpdfview = 0.4.18",
        "app:qpdfview = 0.4.18"　←（ビルドで、使えるようになるアプリ）
    ],
    "requires" : [
        "haiku",　　　　　　←（実行に必要なパッケージ）
        "lib:libdjvulibre",
        "lib:libgl",
        "lib:libmagic",
        "lib:libpoppler",
        "lib:libpoppler_qt5",
        "lib:libqt5concurrent",
        "lib:libqt5core",
        "lib:libqt5gui",
        "lib:libqt5printsupport",
        "lib:libqt5sql",
        "lib:libqt5svg",
        "lib:libqt5widgets"
    ],
    "testRequires" : [],
    "version" : "0.4.18"
}

→残念ながら、レシピの作成時の参考にはなりません。

レシピの記述次第で内容は変化するので、ビルドに成功したレシピでないと完成しない「パッケージ情報」と言えます。ただし、レシピファイルの依存関係がどう認識されているかはわかります。

リポジトリの詳細は、

The Repository を参照

7). HaikuPorter の取り扱い要件

HaikuPorter はPython で実装されているため、Python が必須です

→Python の標準ライブラリのモジュールのみが使用されるため、追加のモジュールをインストールする必要はありません。

Python とは別に、HaikuPorter 自体には次のプログラム/パッケージが必要です:

coreutils
git
tar
unzip
wget
xz_utils

→「 *.xz 」アーカイブとして提供されるポートの場合

ポートのソースは VCS チェックアウトとしてのみ利用可能であるため、これらの VCS のいずれかが必要になる場合があります:

bzr (Bazaar)
cvs
fossil
hg (Mercurial)
svn (Subversion)

8). レシピファイルで定義された依存関係

依存関係を自動的に解決し、ポートを正しい順序でビルドできるようにするために、 HaikuPorter は「レシピファイル」に記述された依存関係を見ています。

Haiku のパッケージ化では、「レシピファイル」に特定のコマンドとライブラリへの依存関係を記述するように強く推奨されています。

レシピファイルの依存の書き方の詳細は、Handling Requirements を参照

和訳はこちら → 7. 「Handling Requirements」レシピの依存の書き方

9). HaikuPorter の使い方:

ヘルプを表示:

haikuporter -h

ポートの作成（パッケージ化の実行）

haikuporter ポート名

使い方の詳細な情報は、Usage を参照

→個人的に使い方を補完しました。

--- - --- - --- - --- - --- - --- - --- - --- - --- - --- - --- - ----- ----- ----- -----

別件: Ubuntu とHaiku で、データをUSB メモリ経由で渡すときの注意:

Haiku でサポートされているのは「Ext2」のフォーマットで、「Ext4」のフォーマットはまだサポートされていません。読み書きに使うのは危険です。

オススメの使い方:

Ubuntu (Fat32) →Haiku にマウント時、「読み取り専用」で開きます:

→Haiku で書き込みしません。

Haiku (BeFS) →Ubuntu にマウントすると、「読み取り専用」で開かれます:

→Ubuntu で書き込みできません。Haiku のファイル属性は利用できません。消えます。

「Fat32」での受け渡しでも、「読み書き」で開くのは、テキストファイルでも危険です。日本語が含まれていると文字化けする可能性が高いです。

Ubuntu (Ext4) →Haiku にマウント時、「読み書き」で開くのは危険:

例えば、「Ubuntu をインストールしたUSB メモリ」をHaiku で「読み書き」で開いたら、「Ext4」のパーティションがマウントできなくなりました。壊れました。

「Home のピクチャ」にある壁紙を使おうと、そのままマウントすると後悔します。USB メモリのUbuntu が立ち上がらないだけでなく、データも消えました。

個人的には、Haiku の「Otter Browser」ブラウザ経由でデータは受け渡し、しています

(1). 「はてなブログ」の「編集の下書き」画面をブックマーク。

(2). データを救える可能性が高いので、ブラウザのタブの設定は、「使っていたページ」を開くです。ただし、そのページは使いません。何かあったら、別のタブでそのページを開いて、そこにデータを写します。

(3). 過去のキャッシュデータを編集してしまうリクスを避けるため、ブログを開く時は、新しいタブで開くのが基本です

(4). スクロールが遅いので、ページの先頭にコメント欄（  ）を作っています。古いデータを編集していないかがわかるように、編集日時を入れておくのがポイント。

追記: 現在は「WebPositive」ブラウザを使っています

最近のシステム更新で「Otter Browser」ブラウザで使われる一部の依存が欠落してインストールできなくなったので、現在は（ブラウザはこれだけなので）「WebPositive」ブラウザを使っています。

（→追記: 本日インストールしてみたら、インストールできました。システム更新で解消されたみたい）

Web フォント（編集時のアイコン）が表示されないのと、突然コケる（システムもコケたりするので注意）、ことを認識していれば、（今のところは）軽いので「Otter Browser」ブラウザよりも快適です。

ブックマークを登録しておき、ブログを編集したらその都度保存して、使わない時はすぐに閉じる、ことを心がけると何とか使えます。使わなくても開いているとコケる（panic に落ちる）ので注意。

最大の利点は、レビュー画面で文字列をマウスで範囲選択してコピーできることです。「Otter Browser」では、ブログの編集ページ等でないと範囲選択できません。これだとブラウザとしてはイマイチ。

画像なら、使えるならホストOS のスクリーンショットを利用します。使えない時は「読み取り専用」で開きます

まとめ

Haiku でのアプリの移植に必要な情報が不確かだったので、イチから学習しなおし。

これだけの情報がネットに散らばっているので、見つけるだけでも大変でした。

ただし、投稿があまり長くなりすぎて、見たい情報を見つけづらくなりました。

はてなブログだと、検索でどのブログにその検索したい文字列があるかはすぐにわかりますが、その箇所には飛べません。ブログは短く書くのが普通なのでしかたないところ。

-

    目次

「投稿の先頭へ」

目次
--- - --- - --- - --- - --- - --- - --- - --- - --- - --- - --- - -
「 Haiku R1/beta3」のデスクトップ
- 「nightly ビルド」のデスクトップ画面:
--- - --- - --- - --- - --- - --- - --- - --- - --- - --- - --- - --
現在のシステムのバージョン:
--- - --- - --- - --- - --- - --- - --- - --- - --- - --- - --- - ---
1. インストールした「haikuporter」に添付の README.md を参照してみる:
- Haikuporter ツール
- Haiku だけのシステムの場合:
- HaikuPorts のインストール:
- ポートをビルド:
- ポートとすべての古い依存関係のポートをビルド
- マルチノードクラスターシステム (Linux + Haiku) の場合:
- Docker を使用したコンテナーでbuildmaster を実行:
- buildmaster を手動でインストール (Linux):
- buildslave をインストールします (Haiku)
- haikuporter の設定ファイルのサンプルを確認:
- ports ツリー（パッケージのカテゴリ分け）を確認:
- git の定義でコミットの管理から外してあるファイルを確認:
- README.md を確認:
--- - --- - --- - --- - --- - --- - --- - --- - --- - --- - --- - ----
2.「haikuports/haikuports wiki」を参照してみる:
- HaikuPorts へようこそ！
- HaikuPorter
- 1). HaikuPorts のインストール:
- 2). haikuports.conf ファイルで、PACKAGER 変数を「自分の名前/メール」に設定します
  - TREE_PATH をhaikuports リポジトリのクローンを作成した場所に設定します
- 3). HaikuPorter ツールをどこからでも実行できるように設定:
  - このガイドの場合は「/boot/home/」に配置:
  - 自分のPC の場合は「/boot/home/Git/」に配置:
- 4). さらに使いやすくするためのツールを準備:
- 参考: Projects のページ
- 参考: より上級のユーザの場合は、HaikuPorts が従うポリシーにも注意
--- - --- - --- - --- - --- - --- - --- - --- - --- - --- - --- - -----
3. 初心者向けの、「HaikuPorter の大まかな紹介（パート1）」を参照してみる:
- A Gentle Introduction to HaikuPorter #1
- 1). Haiku のnightly イメージを使用している場合は、最新のリビジョンにアップグレードします
- 2). 「haikuporter」と「haikuports」をインストール:
- 3). haikuports のソースツリーの場所を設定:
  - 「$TREE_PATH」は、haikuports.conf ファイルで定義されます
--- - --- - --- - --- - --- - --- - --- - --- - --- - --- - --- - ----- -
4. Haiku のports に新しいポートを追加するとき
- 新しいポートを追加するときは、「https://packages.gentoo.org/」の階層を参照:
  - →Gentoo のカテゴリ分けに従います
  - もし、gentoo のパッケージが存在しない場合は、合理的で論理的なカテゴリ分けにします
- 例: 「gtksourceview」パッケージのカテゴリ名を調べる:
--- - --- - --- - --- - --- - --- - --- - --- - --- - --- - --- - ----- --
5. 初心者向けの、「HaikuPorter の大まかな紹介（パート2）」を参照してみる:
- A Gentle Introduction to HaikuPorter #2
- 「A Gentle Introduction to HaikuPorter #1」に記述されていた「素のレシピ」:
- ここでは、「sed-4.4.recipe」のパッケージのレシピを確認しながら学習しました:
- 例: 「sed」パッケージのカテゴリ名を調べる:
- レシピを記述する手順：
- 1). ソースファイルについて調べます:
- 2). 基本となるレシピを作成
- 3). レシピを更新
- 4). レシピをビルドしてパッケージ化
- 5). パッケージをインストール:
  - →移動する前に「/tmp」にコピーした理由
- 6). 動作確認:
- 7). パッケージをアンインストール:
--- - --- - --- - --- - --- - --- - --- - --- - --- - --- - --- - ----- ---
6. 環境変数の説明の「HaikuPorter-BuildRecipes wiki」を参照してみる:
- レシピを作成する
- 概要
- 入力（HaikuPorter →レシピファイルの作成）
- 出力（レシピファイルの作成 →HaikuPorter）
- 入力の環境変数
--- - --- - --- - --- - --- - --- - --- - --- - --- - --- - --- - ----- ----
6-1. 参考: 入力の環境変数の一覧:
- 入力の環境変数の一覧:
- クロスビルドのports ツリーがアクティブな場合、使用可能な変数:
--- - --- - --- - --- - --- - --- - --- - --- - --- - --- - --- - ----- -----
6-2. 参考: 入力のシェル関数の一覧:
- シェル関数の一覧:
--- - --- - --- - --- - --- - --- - --- - --- - --- - --- - --- - ----- ----- -
6-3. 参考: 出力の環境変数の一覧:
- BUILD_PACKAGE_ACTIVATION_PHASE
- BUILD_PACKAGE_ACTIVATION_PHASE
- DISABLE_SOURCE_PACKAGE
- HOMEPAGE
- MESSAGE
- REVISION
- CHECKSUM_SHA256
- PATCHES
- ADDITIONAL_FILES
- SOURCE_DIR
- SOURCE_FILENAME
- SOURCE_URI
- ダウンロード用のURI タイプ:
- チェックアウトのURI タイプ:
- ARCHITECTURES
- BUILD_PREREQUIRES
- BUILD_REQUIRES
- CONFLICTS
- COPYRIGHT
- DESCRIPTION
- FRESHENS
- GLOBAL_WRITABLE_FILES
- LICENSE
- PACKAGE_GROUPS
- PACKAGE_USERS
- POST_INSTALL_SCRIPTS
- PROVIDES
- REPLACES
- REQUIRES
- SUMMARY
- SUPPLEMENTS
- USER_SETTINGS_FILES
--- - --- - --- - --- - --- - --- - --- - --- - --- - --- - --- - ----- ----- --
6-4. 参考: 出力のシェル関数の一覧:
- PATCH()
- BUILD()
- INSTALL()
- TEST()
--- - --- - --- - --- - --- - --- - --- - --- - --- - --- - --- - ----- ----- ---
6-5. 参考: レシピの使用例:
- (1). 簡単なレシピの例（ DESCRIPTION に古いスタイルを使用）:
- (2). 簡単なレシピの例（ DESCRIPTION に推奨されるスタイルを使用）
- (3). 簡単なレシピの例（複数行の著作権に推奨されるスタイルを使用）
- (4). 高度なレシピの例（ DESCRIPTION に古いスタイルを使用）
--- - --- - --- - --- - --- - --- - --- - --- - --- - --- - --- - ----- ----- ----
7. 依存の書き方「Handling Requirements」を参照してみる:
- Provides （提供されるもの）の記述
- Requires（依存）の記述
- Build Requires（ビルド時の依存）の記述
- Build Prerequires（ビルド時の前提条件）の記述
- 「require」の記述は、構文に準拠する必要があります
- コマンドの依存の記述
  - コマンドの名前に含まれるダッシュ（ハイフン）「-」はすべてアンダースコア「_」に置き換えます:
- ランタイムライブラリの依存の記述:
  - コマンドと同様に、ライブラリの名前に含まれるダッシュ（ハイフン）「-」はすべてアンダースコア「_」に置き換えます。
- パッケージの依存の記述:
- 宣言された実際の要件
- 詳細に記述してください！
--- - --- - --- - --- - --- - --- - --- - --- - --- - --- - --- - ----- ----- -----
8. 「HaikuPorter ガイドライン」(HaikuPorter Guidelines) を参照してみる:
- 1). ポートのカテゴリ分け
  - HaikuPorts　に新しいポートを追加するときは、Gentoo Portage　で使用された一致する親ディレクトリの下に新しいポートを作成してください
  - Search Portage & Overlays :検索サイトにてGentoo Portage とそのオーバーレイでパッケージを検索できます
  - これにはいくつかの例外があります
- 2). 一般的なヒント
- 3). レシピファイル内の変数の正しい順序と間隔:
- 4). 備考:
- 5). 「Summary」行
  - 誤り:
  - 正解:
- 6). 「Description」行
  - 誤り:
  - 正解:
  - 最も重要なこと:
- 7). 「HOMEPAGE」行
  - 有効なURL の例:
  - 末尾にスラッシュを追加することは、一部のサイトでは正しいが、他のサイトでは間違っています。
  - レシピのホームページに複数のURLが必要な場合:
- 8). 「Source URI」行
  - sourceforge のファイルダウンロード用の代替リンク形式:
- 9). 「SOURCE_FILENAME」行
- 10). 「SOURCE_DIR」行
- 11). 「Patches」行
- 12). $portName 変数
- 13). Tools パッケージ
- 14). Debuginfo パッケージ
- 15). Versions
- 16). Revisions
- 17). ディレクトリの作成
- 18). commandBinDir ユーザー変数の使用
  - それで:
  - 備考:
- 19). libVersionCompat ユーザー変数の使用
- 20). ハイブリッド対応のレシピファイル
--- - --- - --- - --- - --- - --- - --- - --- - --- - --- - --- - ----- ----- ----- -
9. 「HaikuPorter を使用したパッチ適用」(Patching with HaikuPorterHaikuPorter) を参照してみる:
- 教材のバージョンが上がっています。実際に検証していないので注意
  - 注意: 記述されているコマンドのパラメータの文字が一部抜けていました
- 1). cpio にて、パッチセットを削除し、再作成
- 2). レシピの「BUILD_REQUIRES」で、「devel：libiconv」が必要です
  - →pkgman では、パッケージ指定で「開発パッケージ」であることを指定できるようです
- 3). cpio のパッケージ化を試して、何が起こるかを確認:
- 4). 修正は、makepath.c ファイルの編集:
- 5). 問題が解決したか確認:
  - make_path.c エラーを乗り越えましたが、新しい問題が発生...
- 6). リンカエラーに移る前に、
- 7). リンカーエラーは、Haiku のライブラリの名前がLinux や他のUNIX ライクとは異なるために発生:
- 8). 再び、パッケージを作成:
- 9). 最終的な変更をソースにコミット:
- 10). 最初のウィンドウに戻って、以下を実行:
  - →新しいパッチセットが出来ました！
  - →ソースを編集して「git add」と「git commit」しておけば、新しいパッチセットが自動作成できるみたい
- 11). パッチを有効にします：
- 12). パッチが実際に機能することをテスト:
  - プロセス全体が実行され、最初に、新しいパッチセットを適用したHaikuPorter の出力が表示
  - レシピが完成しました！
- 教材のバージョンが上がっています。実際に検証していないので注意
--- - --- - --- - --- - --- - --- - --- - --- - --- - --- - --- - ----- ----- ----- --
10. Haiku が参考にした、gentoo Linux のパッケージ管理:
- 参考: ebuild ファイル（レシピファイル）の記述について
- Ebuild での依存の記述:
  - 基本的な依存の書き方:
  - 特定のバージョンのパッケージが必要なときの書き方:
- 実際のebuild ファイルの記述を見るには
--- - --- - --- - --- - --- - --- - --- - --- - --- - --- - --- - ----- ----- ----- ---
11. haikuporter のヘルプ表示（和訳）:
--- - --- - --- - --- - --- - --- - --- - --- - --- - --- - --- - ----- ----- ----- ----
12. 追記: HaikuPorter の 2番目のバージョンについての説明:
- 抜粋:
- 1). HaikuPorter の処理:
- 2). HaikuPorter は、
- 3). HaikuPorter 自体には 2つのものが必要です:
  - (1). HaikuPorts.conf
  - (2). ports ツリー
- 4). レシピファイルを作成する
  - (1). HaikuPorter-BuildRecipes
  - (2). HaikuPorter-Guidelines
- 5). ポートとパッケージ
- 6). リポジトリ
- 7). HaikuPorter の取り扱い要件
  - HaikuPorter はPython で実装されているため、Python が必須です
  - Python とは別に、HaikuPorter 自体には次のプログラム/パッケージが必要です:
    - ポートのソースは VCS チェックアウトとしてのみ利用可能であるため、これらの VCS のいずれかが必要になる場合があります:
- 8). レシピファイルで定義された依存関係
  - レシピファイルの依存の書き方の詳細は、Handling Requirements を参照
- 9). HaikuPorter の使い方:
--- - --- - --- - --- - --- - --- - --- - --- - --- - --- - --- - ----- ----- ----- -----
別件: Ubuntu とHaiku で、データをUSB メモリ経由で渡すときの注意:
- オススメの使い方:
- 個人的には、Haiku の「Otter Browser」ブラウザ経由でデータは受け渡し、しています
- 追記: 現在は「WebPositive」ブラウザを使っています
- 画像なら、使えるならホストOS のスクリーンショットを利用します。使えない時は「読み取り専用」で開きます
まとめ
-

「この目次の先頭へ」

「本編の目次に戻る」

目次

--- - --- - --- - --- - --- - --- - --- - --- - --- - --- - --- - -

「 Haiku R1/beta3」のデスクトップ

「nightly ビルド」のデスクトップ画面:

--- - --- - --- - --- - --- - --- - --- - --- - --- - --- - --- - --

現在のシステムのバージョン:

--- - --- - --- - --- - --- - --- - --- - --- - --- - --- - --- - ---

1. インストールした「haikuporter」に添付の README.md を参照してみる:

Haikuporter ツール

Haiku だけのシステムの場合:

HaikuPorts のインストール:

ポートをビルド:

ポートとすべての古い依存関係のポートをビルド

マルチノードクラスターシステム (Linux + Haiku) の場合:

Docker を使用したコンテナーでbuildmaster を実行:

buildmaster を手動でインストール (Linux):

buildslave をインストールします (Haiku)

haikuporter の設定ファイルのサンプルを確認:

ports ツリー（パッケージのカテゴリ分け）を確認:

git の定義でコミットの管理から外してあるファイルを確認:

README.md を確認:

--- - --- - --- - --- - --- - --- - --- - --- - --- - --- - --- - ----

2.「haikuports/haikuports wiki」を参照してみる:

HaikuPorts へようこそ！

HaikuPorter

1). HaikuPorts のインストール:

2). haikuports.conf ファイルで、PACKAGER 変数を「自分の名前/メール」に設定します

TREE_PATH をhaikuports リポジトリのクローンを作成した場所に設定します

3). HaikuPorter ツールをどこからでも実行できるように設定:

このガイドの場合は「/boot/home/」に配置:

自分のPC の場合は「/boot/home/Git/」に配置:

4). さらに使いやすくするためのツールを準備:

「profile」ファイルがまだ存在しない場合は、作成します:

このガイドの場合（ /boot/home/）:

自分のPC の場合（ /boot/home/Git/）:

参考: Projects のページ

参考: より上級のユーザの場合は、HaikuPorts が従うポリシー にも注意

--- - --- - --- - --- - --- - --- - --- - --- - --- - --- - --- - -----

3. 初心者向けの、「HaikuPorter の大まかな紹介（パート1）」を参照してみる:

A Gentle Introduction to HaikuPorter #1

1). Haiku のnightly イメージを使用している場合は、最新のリビジョンにアップグレードします

2). 「haikuporter」と「haikuports」をインストール:

3). haikuports のソースツリーの場所を設定:

「$TREE_PATH」は、haikuports.conf ファイルで定義されます

--- - --- - --- - --- - --- - --- - --- - --- - --- - --- - --- - ----- -

4. Haiku のports に新しいポートを追加するとき

新しいポートを追加するときは、「https://packages.gentoo.org/」の階層を参照:

→Gentoo のカテゴリ分けに従います

もし、gentoo のパッケージが存在しない場合は、合理的で論理的なカテゴリ分けにします

例: 「gtksourceview」パッケージのカテゴリ名を調べる:

「Available Versions」にある一覧の「Version」のバージョン番号「4.8.2」をクリック

HaikuPorter HandlingRequirements を参照すると、依存の指定の仕方の記述がありました。

ここで、 「dependencies」タブ をクリックすると、「依存」が表示:

gtksourceview 4.8.2

--- - --- - --- - --- - --- - --- - --- - --- - --- - --- - --- - ----- --

5. 初心者向けの、「HaikuPorter の大まかな紹介（パート2）」を参照してみる:

A Gentle Introduction to HaikuPorter #2

「A Gentle Introduction to HaikuPorter #1」に記述されていた「素のレシピ」:

ここでは、「sed-4.4.recipe」のパッケージのレシピを確認しながら学習しました:

例: 「sed」パッケージのカテゴリ名を調べる:

「Available Versions」にある一覧の「Version」のバージョン番号「4.8」をクリック

Haiku に存在するパッケージかを確認:

ポートツリーの位置を確認:

参考: ちなみに、サイトでも確認できます:

レシピを記述する手順：

1). ソースファイルについて調べます:

(1). tar.gz やtar.bz2 などのアーカイブファイルの場合の指定:

(2). 特定のコミットハッシュタグを含む Git リポジトリの場合の指定:

(3). サポートされているオプションは、「BuildRecipes」ページを確認

2). 基本となるレシピを作成

(1). 例えば、「sed」を検索すると、/sys-apps/ にあることがわかります:

(2). 学習に使うので、まずは、オリジナルを退避しました:

(3). これで、気兼ねなく目的のファイル「sed-4.4.recipe」を編集できます:

3). レシピを更新

(1). 「SUMMARY=」（要約）は、パッケージの簡単な概要を提供します。最大長は70文字です

(2). 「DESCRIPTION=」（説明）は、パッケージのより長い概要を提供します

(3). 「HOMEPAGE=」は、パッケージの公式 Web サイトへのURL です

(4). 「COPYRIGHT=」は、パッケージに関連付けられている所有権と著作権情報を記述します

(5). 「LICENSE=」は、パッケージで使用される特定のライセンスモデルを定義します。これは有効な定義である必要があります

(6). 「REVISION="3"」に設定されているので、1つ増やします

参考: より上級のユーザの場合は、HaikuPorts が従うポリシーにも注意

ここで、「dependencies」タブをクリックすると、「依存」が表示:

$appsDir:　●

$dataDir:　●

$jobArgs:　●

$portVersion:　●