.\" Generated by scdoc 1.11.4
.\" Complete documentation for this program is not available as a GNU info page
.ie \n(.g .ds Aq \(aq
.el       .ds Aq '
.nh
.ad l
.\" Begin generated content:
.TH "APKBUILD" "5" "2026-06-05"
.PP
.SH "نام (NAME)"
APKBUILD \- اسکریپت ساخت بسته نرمافزاری Alpine
.PP
.SH "خلاصه ساختار (SYNOPSIS)"
.PP
/usr/src/packages/<repo>/<package>/APKBUILD
.PP
.SH "توضیحات (DESCRIPTION)"
.PP
فایل \fBAPKBUILD\fR توسط ابزارهایی مانند \fBabuild\fR(1) برای ساخت بسته جهت نصب نهایی توسط مدیر بسته \fBapk\fR(8) استفاده می‌شود.\& این فایل متاداده‌هایی از قبیل نام بسته، اطلاعات نسخه، مجوز سورس و اطلاعات تماس توسعه‌دهنده را تعریف می‌کند.\& علاوه بر این، شامل دستورات لازم برای ساخت، آزمایش و نصب بسته است.\&
.PP
قالب \fBAPKBUILD\fR مشابه یک اسکریپت شل معمولی است؛ شما متغیرهای از پیش تعریف‌شده را مقداردهی کرده و توابع از پیش تعریف‌شده را پیاده‌سازی می‌کنید، و ابزار \fBabuild\fR(1) (یا ابزارهای مشابه) از آن‌ها برای ایجاد بسته استفاده خواهد کرد.\&
.PP
.SH "متغیرها (VARIABLES)"
.PP
.SS "متغیرهای الزامی (Required Variables)"
.PP
متغیرهای زیر باید در تمام فایل‌های \fBAPKBUILD\fR تنظیم شوند:
.PP
\fBpkgname\fR
.RS 4
نام بسته را مشخص می‌کند.\& این مقدار معمولاً نام بالادستی بسته است؛ با این حال، توجه داشته باشید که تمام حروف باید کوچک باشند.\&
.PP
کتابخانه‌های زبان‌های اسکریپت‌نویسی باید پیشوندی پیش از نام کتابخانه داشته باشند که بیانگر زبان مربوطه باشد.\& چنین پیشوندهایی شامل \fIlua-\fR، \fIperl-\fR، \fIpy-\fR و \fIrb-\fR هستند.\& همه زبان‌ها از پیشوند استفاده نمی‌کنند.\& برای یک فهرست قطعی، به فایل PREFIXES در دایرکتوری ریشه مخزنی که برای بسته‌بندی استفاده می‌کنید مراجعه فرمایید.\&
.PP
.RE
\fBpkgver\fR
.RS 4
نسخه نرم‌افزاری که بسته‌بندی می‌شود را مشخص می‌کند.\& نسخه یک بسته باید شامل یک یا چند عدد باشد که با ممیز/نقطه اعشار (radix) از هم جدا شده‌اند.\& عدد پایانی ممکن است برای پروژه‌های بالادستی که از چنین طرح شماره‌گذاری نسخه‌ای استفاده می‌کنند (مانند 1.\&5a، 1.\&5b، 1.\&5c)، دارای یک حرف منفرد در ادامه باشد.\&
.PP
پس از عدد نهایی (و حرف منفرد اختیاری)، ممکن است یک یا چند پسوند اضافه شود که باید یک زیرخط (_) به همراه یکی از موارد \fIalpha\fR، \fIbeta\fR، \fIpre\fR، \fIrc\fR، \fIcvs\fR، \fIsvn\fR، \fIgit\fR، \fIhg\fR یا \fIp\fR باشد، و به‌صورت اختیاری یک عدد دیگر نیز به دنبال آن بیاید.\& اگر پسوند یکی از مقادیر \fIalpha\fR، \fIbeta\fR، \fIpre\fR یا \fIrc\fR باشد، قدیمی‌تر از نسخه بدون این پسوند در نظر گرفته می‌شود؛ اگر پسوند یکی از مقادیر \fIcvs\fR، \fIsvn\fR، \fIgit\fR، \fIhg\fR یا \fIp\fR باشد، جدیدتر از نسخه بدون این پسوند در نظر گرفته می‌شود.\& تمامی مثال‌های زیر نسخه‌های معتبر هستند، به ترتیب از کمترین به بیشترین:
.PP
1.\&0, 1.\&1_alpha2, 1.\&1.\&3_pre, 1.\&1.\&3_pre_p2, 1.\&1.\&3, 1.\&1.\&3_hg, 1.\&2, 1.\&2a, 1.\&2b
.PP
.RE
\fBpkgrel\fR
.RS 4
شماره انتشار بسته برای این نسخه خاص را مشخص می‌کند.\& این متغیر نشان‌دهنده زمانی است که بسته بدون تغییر در نسخه بالادستی دچار دگرگونی شده است.\& هر زمان که محتوا، وابستگی‌ها یا متاداده‌های یک بسته را تغییر می‌دهید، همیشه \fBpkgrel\fR را افزایش دهید.\& نخستین انتشار از یک بسته همواره 0 است.\&
.PP
.RE
\fBpkgdesc\fR
.RS 4
مشخص می‌کند که بسته شامل چه مواردی است.\& مقدار \fBpkgdesc\fR باید ۱۲۸ نویسه یا کمتر باشد و باید به طور موجز توصیف کند که نرم‌افزار یا محتویات بسته‌بندی‌شده به کاربر اجازه انجام چه کارهایی را می‌دهند.\& برای نمونه،
“Fully-featured word processor with spell check and plugins”
یک مقدار مناسب برای \fBpkgdesc\fR در برنامه AbiWord خواهد بود.\&
.PP
.RE
\fBurl\fR
.RS 4
نشانی وب پروژه بالادستی بسته را مشخص می‌کند.\& این آدرس به کاربران و نگه‌دارندگان آینده امکان می‌دهد مستندات، اطلاعات انتشار و اطلاعات تماس مربوط به بسته را پیدا کنند.\& اگر هیچ نشانی وبی برای بسته در دسترس نیست، باید \fBurl\fR را روی یک رشته خالی ("") تنظیم کنید.\&
.PP
.RE
\fBarch\fR
.RS 4
معماری‌هایی را مشخص می‌کند که بسته می‌تواند برای آن‌ها ساخته شود.\& اکیداً توصیه می‌شود در صورتی که بسته قابل‌حمل (portable) است، این متغیر را روی "\fIall\fR" تنظیم کنید.\&
.PP
در صورتی که بسته حاوی هیچ فایل باینری وابسته به معماری نیست - یعنی فایل‌هایی که فقط برای معماری مقصد کامپایل شده باشند - می‌توانید از "\fInoarch\fR" استفاده کنید.\& چنین بسته‌هایی ممکن است شامل بسته‌های پایتون خالص، بسته‌های اسکریپت شل و فایل‌های JAR باشند.\& اگر مطمئن نیستید این موضوع به چه معناست، استفاده از "\fIall\fR" ایمن و بی‌خطر است.\&
.PP
معماری‌ها را می‌توان با استفاده از نویسه \fI!\&\fR نفی کرد تا از فهرست معماری‌های پشتیبانی‌شده خارج شوند.\& به عنوان مثال، \fIarch="all !\&ppc64le"\fR به این معنی است که بسته اجازه دارد بر روی تمامی معماری‌ها به جز معماری ppc64le ساخته شود.\&
.PP
.RE
\fBlicense\fR
.RS 4
مجوزی که بسته تحت آن توزیع می‌شود را مشخص می‌کند.\& مقدار ارائه‌شده باید با یک شناسه مجوز SPDX همخوانی داشته باشد.\&
.PP
.RE
\fBsource\fR
.RS 4
محل فایل‌های سورس محلی و راه دور مورد استفاده برای ساخت بسته را مشخص می‌کند.\& معمولاً فایل(های) سورس یا آرشیو(های) راه دور مشخص می‌شوند، و در ادامه وصله‌ها (patches) محلی، فایل‌های پیکربندی یا سایر فایل‌های ضروری ذکر می‌گردند.\&
.PP
.PP
.RE
.SS "متغیرهای اختیاری (Optional Variables)"
.PP
متغیرهای زیر الزامی نیستند، اما می‌توانند در هر فایل \fBAPKBUILD\fR تنظیم شوند.\&
.PP
\fBcheckdepends\fR
.RS 4
وابستگی‌های زمان آزمایش (test-time) بسته را مشخص می‌کند.\& بسته‌های متداولی که برای آزمایش استفاده می‌شوند عبارتند از check، dejagnu و perl-test-command.\&
.PP
.RE
\fBdepends\fR
.RS 4
وابستگی‌های زمان اجرای (run-time) بسته را مشخص می‌کند.\& ابزار \fBabuild\fR(1) به طور خودکار بسته نهایی را برای یافتن وابستگی‌های کتابخانه اشتراکی (.\&so) اسکن می‌کند؛ آن‌ها را در اینجا مشخص نکنید.\&
.PP
.RE
\fBinstall\fR
.RS 4
اسکریپت‌های نصب بسته را، در صورت وجود، مشخص می‌کند.\& برای اطلاعات بیشتر درباره اسکریپت‌های نصب، بخش \fIاسکریپت‌های نصب\fR را ببینید.\&
.PP
.RE
\fBinstall_if\fR
.RS 4
شرطی را مشخص می‌کند که در صورت برقراری آن، \fBapk\fR(8) باید بسته (یا زیربسته) را به طور خودکار نصب کند.\& برای نمونه، زیربسته‌های OpenRC این متغیر را به صورت زیر تنظیم می‌کنند:
.PP
.nf
.RS 4
install_if="openrc ${subpkgname%-openrc}=$pkgver-r$pkgrel"
.fi
.RE
.PP
که به این معنی است که زیربسته OpenRC به طور خودکار نصب خواهد شد اگر هم OpenRC و هم بسته مبدأ (origin) روی همان سیستم نصب شده باشند.\&
.PP
.RE
\fBmakedepends\fR
.RS 4
وابستگی‌های زمان ساخت را برای بسته مشخص می‌کند.\&
.PP
.RE
\fBmaintainer\fR
.RS 4
نام و نشانی ایمیل نگه‌دارنده بسته در قالب RFC 2822.\&
برای نمونه: \fImaintainer="Joe Q.\& Public <john.\&q.\&public@example.\&com>"\fR
.PP
.RE
\fBpkggroups\fR
.RS 4
فهرستی از گروه‌های ورود را مشخص می‌کند که با فاصله از هم جدا شده‌اند تا در زمان ساخت ایجاد شوند.\& توجه داشته باشید که باید گروه‌های ورود را در یک اسکریپت پیش از نصب (pre-install) نیز ایجاد کنید؛ برای اطلاعات بیشتر درباره اسکریپت‌های نصب، بخش \fIاسکریپت‌های نصب\fR را ببینید.\&
.PP
.RE
\fBpkgusers\fR
.RS 4
فهرستی از کاربران ورود را مشخص می‌کند که با فاصله از هم جدا شده‌اند تا در زمان ساخت ایجاد شوند.\& توجه داشته باشید که باید کاربران ورود را در یک اسکریپت پیش از نصب نیز ایجاد کنید؛ برای اطلاعات بیشتر درباره اسکریپت‌های نصب، بخش \fIاسکریپت‌های نصب\fR را ببینید.\&
.PP
.RE
\fBprovides\fR
.RS 4
مشخص می‌کند که بسته محتوایی مشابه با بسته دیگری را «فراهم» (provides) می‌کند.\& دو قالب وجود دارد که می‌توانید برای \fBprovides\fR استفاده کنید: یک نام فراهم‌کننده، و یک نام فراهم‌کننده به همراه نسخه.\&
.PP
مشخص کردن نام فراهم‌کننده همراه با نسخه مانند \fIfoobar=1.\&2\fR باعث می‌شود بسته به عنوان یک «نام مستعار» (alias) از \fIfoobar\fR نسخه \fI1.\&2\fR عمل کند.\& در صورتی که کاربر دستوری مانند `apk add foobar` یا مشابه آن را اجرا کند، این بسته به صورت خودکار نصب می‌شود و با بسته‌ای به نام \fIfoobar\fR تداخل خواهد داشت.\&
.PP
مشخص کردن نام فراهم‌کننده بدون نسخه مانند \fIbaz\fR باعث می‌شود بسته یک فراهم‌کننده «مجازی» به نام \fIbaz\fR ارائه دهد.\& چندین بسته با فراهم‌کننده مجازی یکسان می‌توانند روی یک سیستم نصب شوند؛ با این حال، اگر کاربری دستور `apk add baz` را اجرا کند، فهرستی از بسته‌های ارائه‌دهنده \fIbaz\fR به او نمایش داده می‌شود و باید یکی را انتخاب و نصب نماید.\&
.PP
.RE
\fBprovider_priority\fR
.RS 4
مقدار عددی را مشخص می‌کند که \fBapk\fR(8) هنگام ارزیابی اینکه کدام فراهم‌کننده برای یک ارائه‌دهنده مجازی \fBprovides\fR یکسان باید نصب شود، استفاده می‌کند.\&
.PP
.RE
\fBreplaces\fR
.RS 4
بسته‌هایی را مشخص می‌کند که این بسته جایگزین آن‌ها می‌شود.\& این مقدار معمولاً برای بسته‌هایی استفاده می‌شود که توسط بالادستی تغییر نام یافته‌اند.\&
.PP
.RE
\fBreplaces_priority\fR
.RS 4
مقدار عددی مورد استفاده توسط \fBapk\fR(8) را مشخص می‌کند زمانی که چندین بسته دارای \fBreplaces\fR شامل فایلی یکسان باشند.\& این متغیر همچنین برای تصمیم‌گیری در مورد اینکه کدام بسته باید مجوزهای یک دایرکتوری را حتی بدون تنظیم \fBreplaces\fR تعیین کند استفاده می‌شود.\&
.PP
.RE
\fBsubpackages\fR
.RS 4
زیربسته‌ها یا بسته‌های تفکیک‌شده (split packages) ساخته‌شده همراه با این بسته را مشخص می‌کند.\& معمولاً این مقدار شامل \fI$pkgname-dev\fR برای فایل‌های توسعه (مانند \fI/usr/include\fR و فایل‌های کتابخانه ایستا) و \fI$pkgname-doc\fR برای مستندات (مانند \fI/usr/share/doc\fR و \fI/usr/share/man\fR) است.\&
.PP
به‌طور پیش‌فرض، تابع تفکیک همان بخش پایانی نام بسته پس از آخرین خط تیره است.\& بنابراین برای \fI$pkgname-foo\fR و \fIlibfoo\fR تابع تفکیک به ترتیب \fIfoo\fR و \fIlibfoo\fR خواهد بود.\& نام سفارشی تابع تفکیک را می‌توان با استفاده از \fIfoo:funcname\fR تعیین کرد.\& مشابه تابع \fBpackage\fR، تابع تفکیک باید پس از ایجاد \fI$subpkgdir\fR، فایل‌ها را از \fI$pkgdir\fR (که دایرکتوری کاری پیش‌فرض است) یا \fI$srcdir\fR به \fI$subpkgdir\fR منتقل کند.\&
.PP
به‌طور پیش‌فرض، مقدار \fBarch\fR مشخص می‌کند که آیا یک زیربسته مستقل از معماری در نظر گرفته شود یا خیر.\& این رفتار را می‌توان با استفاده از \fIfoo::noarch\fR یا \fIfoo:funcname:all\fR تغییر داد.\&
.PP
هنگامی که چندین زیربسته مشخص می‌شوند، توابع تفکیک آن‌ها به ترتیبی که در \fBsubpackages\fR قید شده‌اند اجرا خواهند شد.\&
.PP
.RE
\fBtriggers\fR
.RS 4
اسکریپت‌های محرک (trigger scripts) مورد استفاده توسط (زیر)بسته‌های مشخص‌شده را تعیین می‌کند.\& یک اسکریپت محرک، اسکریپتی به زبان شل است که هر زمان فایل‌ها یا دایرکتوری‌های تحت نظارت تغییر یابند، فراخوانی می‌شود.\& می‌توانید مسیرهای مورد نظر برای نظارت را با استفاده از متغیر triggers به صورت زیر تعیین کنید:
.PP
.nf
.RS 4
$pkgname\&.trigger=/usr/share/man:/usr/local/share/man
.fi
.RE
.PP
این دستور اسکریپت محرک را برای \fI$pkgname\fR هر زمان که فایل‌هایی در \fI/usr/share/man\fR یا \fI/usr/local/share/man\fR ایجاد، اصلاح یا حذف شوند، اجرا خواهد کرد.\&
.PP
.RE
\fBoptions\fR
.RS 4
متغیر \fBoptions\fR به شما امکان می‌دهد پارامترهایی را برای بسته در زمان ساخت تنظیم کنید.\& چندین گزینه معتبر وجود دارد که می‌توانید تنظیم نمایید، و می‌توانید چند گزینه را با قرار دادن فاصله میان هر یک از آن‌ها مشخص کنید.\&
نام‌های سفارشی گزینه‌ها زمانی قابل استفاده هستند که دقیقاً شامل یک نویسه \fI:\fR باشند.\&
گزینه‌ها را می‌توان برای یک (زیر)بسته خاص با استفاده از \fIsubpkgname::option\fR (یا \fIsubpkgname:option\fR برای گزینه‌های سفارشی) تنظیم کرد.\&
.PP
\fB!\&archcheck\fR
.RS 4
مشخص می‌کند بسته شامل باینری‌هایی است که نمی‌توانند بر روی معماری مقصد اجرا شوند.\& این گزینه در درجه اول برای بسته‌های حاوی میان‌افزار (firmware) استفاده می‌شود و معمولاً نباید هرگز مورد نیاز باشد.\&
.PP
.RE
\fBbigdocs\fR
.RS 4
مشخص می‌کند که این بسته عمداً دارای یک زیربسته doc- بزرگ است.\& بدین ترتیب، از ارسال هشدار در صورتی که حجم زیربسته doc- از آستانه خاصی (در حال حاضر ۲ مبی‌بایت) فراتر رود جلوگیری می‌کند.\&
.PP
.RE
\fBcharset.\&alias\fR
.RS 4
مشخص می‌کند که بسته فایلی با نام \fI/usr/lib/charset.\&alias\fR به همراه دارد و این فایل باید روی سیستم کاربر نصب شود.\& این حالت تقریباً هرگز اتفاق نمی‌افتد.\& از این گزینه استفاده نکنید.\&
.PP
.RE
\fB!\&check\fR
.RS 4
مشخص می‌کند که بسته مجموعه آزمون‌ها را اجرا نخواهد کرد.\& دلیل غیرفعال‌سازی مرحله بررسی (check) باید در قالب یک کامنت یادداشت شود.\&
.PP
.RE
\fBcheckroot\fR
.RS 4
مشخص می‌کند که مجموعه آزمون‌های این بسته در fakeroot(8) اجرا خواهد شد.\& این امر برای برخی مجموعه‌های آزمایشی که اجرای آن‌ها توسط کاربر غیر ریشه با شکست مواجه می‌شود ضروری است.\&
.PP
.RE
\fB!\&dbg\fR
.RS 4
مشخص می‌کند که بسته نباید به همراه یک بسته اطلاعات اشکال‌زدایی (debug) ساخته شود.\& این حالت پیش‌فرض است مگر اینکه DEFAULT_DBG در متغیرهای محیطی یا در abuild.\&conf(5) تنظیم شده باشد.\& این گزینه معمولاً در بسته‌هایی استفاده می‌شود که اطلاعات دیباگ تولید نمی‌کنند (مانند بسته‌های خالص پایتون) یا بسته‌هایی که از بسته‌های اطلاعات دیباگ پشتیبانی نمی‌کنند.\&
.PP
.RE
\fB!\&fhs\fR
.RS 4
مشخص می‌کند که بسته استاندارد FHS را نقض کرده و در مکانی مانند \fI/usr/local\fR، \fI/opt\fR یا \fI/srv\fR نصب می‌شود.\&
.PP
.RE
\fBldpath-recursive\fR
.RS 4
مشخص می‌کند که ابزار \fBabuild\fR(1) هنگام تلاش برای یافتن وابستگی‌های کتابخانه اشتراکی (.\&so) برای بسته، باید از آرگومان \fB--recursive\fR در scanelf(1) استفاده کند.\&
.PP
.RE
\fBlib64\fR
.RS 4
مشخص می‌کند که بسته فایل‌ها را تحت \fI/lib64\fR یا \fI/usr/lib64\fR نصب می‌کند و بررسی مربوط به آن دایرکتوری‌ها باید نادیده گرفته شود.\& این عمل منع شده است و فقط باید برای بسته‌هایی استفاده شود که سازگاری با GNU libc را فراهم می‌کنند.\&
.PP
.RE
\fBlibtool\fR
.RS 4
مشخص می‌کند که بسته به فایل‌های libtool (.\&la) خود نیاز دارد.\& این فایل‌ها به طور خودکار توسط \fBabuild\fR(1) حذف نخواهند شد.\&
.PP
.RE
\fBnet\fR
.RS 4
مشخص می‌کند که سیستم ساخت بسته نیازمند دسترسی به شبکه است.\& این اقدام منع شده است و باید یک گزارش مشکل (issue) برای نویسندگان بسته ثبت گردد.\&
.PP
.RE
\fB!\&strip\fR
.RS 4
مشخص می‌کند که نباید دستور strip(1) بر روی هیچ‌یک از باینری‌های بسته اجرا شود.\& در صورتی که متغیر DEBUG تنظیم شده باشد، این مورد به طور خودکار اعمال می‌شود.\&
.PP
.RE
\fBsuid\fR
.RS 4
مشخص می‌کند که باینری‌های موجود در بسته ممکن است به صورت set-uid نصب شوند.\& این یک ریسک امنیتی است و اکیداً توصیه می‌شود در صورت امکان به جای set-uid از قابلیت‌ها (capabilities) یا جداسازی فرایندها استفاده شود.\&
.PP
.RE
\fBsetcap\fR
.RS 4
مشخص می‌کند باینری‌های بسته ممکن است با قابلیت‌های اضافی setcap(8) نصب شوند.\& در صورت فعال بودن این گزینه، اکیداً توصیه می‌شود این باینری‌ها فقط توسط ریشه و کاربران یک گروه خاص قابل اجرا باشند، نه توسط دیگران.\&
.PP
.RE
\fBtextrels\fR
.RS 4
مشخص می‌کند باینری‌های بسته دارای بازنشانی‌ها (relocations) روی بخش‌های متنی هستند.\& به‌طور پیش‌فرض، \fBabuild\fR(1) از ساخت چنین بسته‌ای خودداری می‌کند چرا که این مورد یک دغدغه امنیتی به شمار می‌رود.\&
.PP
.RE
\fBtoolchain\fR
.RS 4
مشخص می‌کند که بسته بخشی از مجموعه ابزارهای پایه (base toolchain) است و ممکن است به بسته‌هایی مانند \fIg++\fR وابسته باشد.\&
.PP
.RE
\fB!\&tracedeps\fR
.RS 4
مشخص می‌کند که \fBabuild\fR(1) نباید به طور خودکار \fBdepends\fR و \fBprovides\fR را با کتابخانه‌های اشتراکی (.\&so)، مقاصد پیوندهای نمادین و موارد مشابه پر کند.\&
.PP
.PP
.RE
.RE
.SS "متغیرهای خودکار (Automatic Variables)"
.PP
متغیرهای زیر توسط \fBabuild\fR(1) برای شما تعریف می‌شوند، اما در صورت لزوم می‌توان مقدار آن‌ها را بازتعریف کرد.\&
.PP
\fBbuilddir\fR
.RS 4
دایرکتوری محل ساخت کد منبع بسته را مشخص می‌کند.\& مقدار پیش‌فرض \fI$srcdir/$pkgname-$pkgver\fR است که برای اکثر توزیع‌های کد منبع مناسب است.\& اگر تاربال سورس پس از استخراج، دایرکتوری \fI$pkgname-$pkgver\fR را ایجاد نمی‌کند، باید \fBbuilddir\fR را بازتعریف نمایید.\&
.PP
.RE
\fBpkgdir\fR
.RS 4
دایرکتوری محل نصب فایل‌های ساخته‌شده را مشخص می‌کند.\& معمولاً برای نصب فایل‌ها دستور `make DESTDIR="$pkgdir" install` یا مشابه آن را فراخوانی می‌کنید.\& مقدار پیش‌فرض \fI$startdir/pkg\fR است و نباید این متغیر را تغییر دهید.\&
.PP
.RE
\fBsrcdir\fR
.RS 4
دایرکتوری محل دانلود و استخراج فایل‌های مشخص‌شده در \fBsource\fR را مشخص می‌کند.\& مقدار پیش‌فرض \fI$startdir/src\fR است و نباید نیازی به تغییر آن داشته باشید.\&
.PP
.RE
\fBstartdir\fR
.RS 4
دایرکتوری محل استقرار فایل \fBAPKBUILD\fR را مشخص می‌کند.\& معمولاً نباید از این متغیر استفاده شود.\&
.PP
.RE
\fBsubpkgdir\fR
.RS 4
دایرکتوری محل قرارگیری فایل‌های زیربسته را مشخص می‌کند.\& این متغیر تنها در داخل توابع زیربسته مقداردهی می‌شود.\&
.PP
.PP
.RE
.SS "متغیرهای ویژه (Special Variables)"
.PP
متغیرهای زیر تنها در شرایط خاص به کار می‌روند، و بسته به نحوه استفاده و محتوای سایر متغیرها ممکن است الزامی یا اختیاری باشند.\&
.PP
\fBdepends_dev\fR
.RS 4
وابستگی‌های زمان اجرای زیربسته \fI-dev\fR.\&
.PP
.RE
\fBdepends_doc\fR
.RS 4
وابستگی‌های زمان اجرای زیربسته \fI-doc\fR.\&
.PP
.RE
\fBdepends_libs\fR
.RS 4
وابستگی‌های زمان اجرای زیربسته \fI-libs\fR.\&
.PP
.RE
\fBdepends_openrc\fR
.RS 4
وابستگی‌های زمان اجرای زیربسته \fI-openrc\fR.\&
.PP
.RE
\fBdepends_static\fR
.RS 4
وابستگی‌های زمان اجرای زیربسته \fI-static\fR.\&
.PP
.RE
\fBdepends_systemd\fR
.RS 4
وابستگی‌های زمان اجرای زیربسته \fI-systemd\fR.\&
.PP
.RE
\fBdepends_udev\fR
.RS 4
وابستگی‌های زمان اجرای زیربسته \fI-udev\fR.\&
.PP
.RE
\fBgiturl\fR
.RS 4
نشانی اینترنتی (URL) مخزن Git جهت استفاده با دستور `abuild snapshot`.\& اگر شاخه پیش‌فرض مخزن مد نظر نباشد، می‌توان با افزودن \fB-b\fR \fIbranch\fR شاخه دیگری را مشخص کرد که در آن \fIbranch\fR همان شاخه‌ای است که باید دریافت (checkout) شود.\&
.PP
.PP
.RE
.SH "توابع (FUNCTIONS)"
.PP
توابع مشخص‌شده در اینجا ممکن است در هر فایل \fBAPKBUILD\fR حضور داشته باشند، اما به استثنای تابع \fBpackage\fR، اکیداً الزامی نیستند.\&
.PP
\fBfetch\fR
.RS 4
این تابع برای دانلود فایل‌های راه دور موجود در \fBsource\fR فراخوانی می‌شود.\&
.PP
.RE
\fBunpack\fR
.RS 4
این تابع تمامی آرشیوهای موجود در \fBsource\fR را درون \fBsrcdir\fR استخراج می‌کند.\&
.PP
.RE
\fBprepare\fR
.RS 4
کد منبع موجود در \fBsrcdir\fR را برای ساخت آماده‌سازی می‌کند.\& تابع پیش‌فرض \fBprepare\fR اطمینان حاصل می‌کند که دایرکتوری‌های ساخت به درستی تنظیم شده‌اند و هرگونه فایل \fI*.\&patch\fR مشخص‌شده در \fBsource\fR را اعمال می‌کند.\& در صورت نگارش یک تابع سفارشی \fBprepare\fR، باید \fBdefault_prepare\fR را فراخوانی کنید.\&
.PP
یک تابع سفارشی \fBprepare\fR ممکن است \fBupdate_config_sub\fR یا \fBupdate_config_guess\fR را به ترتیب برای به‌روزرسانی فایل‌های \fBconfig.\&sub\fR و \fBconfig.\&guess\fR فراخوانی کند.\&
.PP
.RE
\fBbuild\fR
.RS 4
کد منبع موجود در \fBbuilddir\fR را کامپایل می‌کند.\& شما باید این تابع را خودتان پیاده‌سازی کنید.\& در صورتی که نیازی به کامپایل نباشد، می‌توانید از آن صرف‌نظر کنید.\&
.PP
.RE
\fBcheck\fR
.RS 4
مجموعه آزمون‌های بسته را اجرا می‌کند.\& این تابع باید پیاده‌سازی شود مگر اینکه \fB!\&check\fR در \fBoptions\fR تعیین شده باشد.\&
.PP
.RE
\fBpackage\fR
.RS 4
بسته را درون \fBpkgdir\fR نصب می‌کند.\& توجه داشته باشید که \fBpkgdir\fR برای شما ایجاد نمی‌شود؛ اگر این بسته هیچ فایلی نصب نمی‌کند (برای نمونه یک متپکیج)، برای رد شدن از فاز بسته‌بندی باید از `mkdir -p "$pkgdir"` استفاده کنید.\&
.PP
.PP
.RE
.SS "اسکریپت‌های نصب (Install Scripts)"
.PP
یک اسکریپت نصب زمانی اجرا می‌شود که عملیاتی بر روی بسته توسط \fBapk\fR(8) صورت گیرد.\& اسکریپت نصب باید به زبان شل نوشته شود و اعلان مفسر \fI#!\&/bin/sh\fR به عنوان خط نخست آن قرار گیرد.\& متغیر \fBinstall\fR باید حاوی اسکریپت‌های نصب مورد نیاز بسته باشد.\&
.PP
اسکریپت نصب درون فایل‌سیستم ریشه‌ای که بسته در آن نصب می‌شود اجرا خواهد شد.\& یک آرگومان منفرد به اسکریپت‌های فراخوانی ارسال می‌شود که نسخه بسته‌ای است که در حال حاضر نصب (یا حذف) می‌شود.\& اسکریپت‌های پیش از ارتقا (pre-upgrade) و پس از ارتقا (post-upgrade) یک آرگومان دوم اضافی نیز خواهند داشت که نسخه بسته پیش از فرآیند ارتقا را مشخص می‌کند.\&
.PP
عملیات‌های مختلفی که ممکن است اسکریپت‌های نصب برای آن‌ها مشخص شوند به شرح زیر هستند:
.PP
\fB$pkgname.\&pre-install\fR
.RS 4
پیش از نصب بسته اجرا می‌شود.\& اگر این اسکریپت با خطا (کد خروج غیر صفر) پایان یابد، \fBapk\fR(8) عملیات نصب را متوقف کرده و بسته نصب نخواهد شد.\& این اسکریپت نصب معمولاً برای ایجاد کاربران یا گروه‌های مورد نیاز همان‌طور که در \fBpkggroups\fR و \fBpkgusers\fR شرح داده شده به کار می‌رود.\&
.PP
.RE
\fB$pkgname.\&post-install\fR
.RS 4
پس از نصب بسته اجرا می‌شود.\& اگر این اسکریپت با خطا (کد خروج غیر صفر) خاتمه یابد، \fBapk\fR(8) بسته را به عنوان خراب (broken) علامت‌گذاری می‌کند.\& در صورت وقوع این حالت، دستور `apk fix` تلاش خواهد کرد اسکریپت post-install را مجدداً اجرا کند.\&
.PP
.RE
\fB$pkgname.\&pre-upgrade\fR
.RS 4
پیش از ارتقای بسته اجرا می‌شود.\& اگر این اسکریپت با خطا (کد خروج غیر صفر) پایان یابد، \fBapk\fR(8) بسته را به عنوان خراب علامت‌گذاری خواهد کرد.\&
.PP
.RE
\fB$pkgname.\&post-upgrade\fR
.RS 4
پس از ارتقای بسته اجرا می‌شود.\& اگر این اسکریپت با خطا (کد خروج غیر صفر) خاتمه یابد، \fBapk\fR(8) بسته را به عنوان خراب علامت‌گذاری می‌کند.\& در صورت وقوع این اتفاق، دستور `apk fix` تلاش خواهد کرد اسکریپت post-upgrade را دوباره اجرا کند.\&
.PP
.RE
\fB$pkgname.\&pre-deinstall\fR
.RS 4
پیش از حذف بسته از سیستم اجرا می‌شود.\& اگر این اسکریپت با خطا (کد خروج غیر صفر) پایان یابد، \fBapk\fR(8) بسته را از روی سیستم حذف نخواهد کرد.\&
.PP
.RE
\fB$pkgname.\&post-deinstall\fR
.RS 4
پس از حذف بسته از سیستم اجرا می‌شود.\& خروج همراه با خطا هیچ تأثیری نخواهد داشت.\&
.PP
.PP
.RE
.SH "نکات پیاده‌سازی (IMPLEMENTATION NOTES)"
.PP
در حال حاضر، فایل‌های \fBAPKBUILD\fR مانند اسکریپت‌های شل معمولی source می‌شوند.\& این شیوه ممکن است در آینده تغییر یابد.\&
.PP
.PP
.SH "سازگاری (COMPATIBILITY)"
.PP
ابزار \fBabuild\fR(1) به شکلی که توسط Alpine Linux توزیع شده است از شل BusyBox Almquist استفاده می‌کند، بخشی از \fBbusybox\fR(1) که در حال حاضر فاقد مستندات است.\& این شل عمدتاً با استاندارد IEEE Std 1003.\&2 (“POSIX.\&2”) و به همراه برخی افزونه‌های شبیه به bash سازگار است.\& ابزار \fBabuild\fR(1) به شکلی که توسط Adélie توزیع شده است از /bin/sh ترجیحی کاربر استفاده می‌کند که معمولاً \fBbash\fR(1) است.\&
.PP
.PP
.SH "همچنین ببینید (SEE ALSO)"
.PP
مرجع مجوز SPDX (در وب در <https://spdx.\&org/licenses>)،
\fBabuild\fR(1)،
\fBnewapkbuild\fR(1)،
\fBapk\fR(8)،
\fBbuildrepo\fR(1)،
\fBap\fR(1)،
\fBcheckapk\fR(1).\&
.PP
.PP
.SH "تاریخچه (HISTORY)"
.PP
قالب \fBAPKBUILD\fR و ابزار \fBabuild\fR(1) نخستین بار در Alpine Linux 1.\&9 پدیدار شدند.\&
.PP
.PP
.SH "نویسندگان (AUTHORS)"
.PP
Timo Teräs <\fItimo.\&teras@iki.\&fi\fR>
.br
Natanael Copa <\fIncopa@alpinelinux.\&org\fR>
.PP
مستندات:
.br
A.\& Wilcox <\fIawilfox@adelielinux.\&org\fR>
.PP