APKBUILD(5) File Formats Manual APKBUILD(5)

APKBUILD - اسکریپت ساخت بسته نرمافزاری Alpine

/usr/src/packages/<repo>/<package>/APKBUILD

فایل APKBUILD توسط ابزارهایی مانند abuild(1) برای ساخت بسته جهت نصب نهایی توسط مدیر بسته apk(8) استفاده می‌شود. این فایل متاداده‌هایی از قبیل نام بسته، اطلاعات نسخه، مجوز سورس و اطلاعات تماس توسعه‌دهنده را تعریف می‌کند. علاوه بر این، شامل دستورات لازم برای ساخت، آزمایش و نصب بسته است.

قالب APKBUILD مشابه یک اسکریپت شل معمولی است؛ شما متغیرهای از پیش تعریف‌شده را مقداردهی کرده و توابع از پیش تعریف‌شده را پیاده‌سازی می‌کنید، و ابزار abuild(1) (یا ابزارهای مشابه) از آن‌ها برای ایجاد بسته استفاده خواهد کرد.

متغیرهای زیر باید در تمام فایل‌های APKBUILD تنظیم شوند:

pkgname

نام بسته را مشخص می‌کند. این مقدار معمولاً نام بالادستی بسته است؛ با این حال، توجه داشته باشید که تمام حروف باید کوچک باشند.

کتابخانه‌های زبان‌های اسکریپت‌نویسی باید پیشوندی پیش از نام کتابخانه داشته باشند که بیانگر زبان مربوطه باشد. چنین پیشوندهایی شامل lua-، perl-، py- و rb- هستند. همه زبان‌ها از پیشوند استفاده نمی‌کنند. برای یک فهرست قطعی، به فایل PREFIXES در دایرکتوری ریشه مخزنی که برای بسته‌بندی استفاده می‌کنید مراجعه فرمایید.

pkgver

نسخه نرم‌افزاری که بسته‌بندی می‌شود را مشخص می‌کند. نسخه یک بسته باید شامل یک یا چند عدد باشد که با ممیز/نقطه اعشار (radix) از هم جدا شده‌اند. عدد پایانی ممکن است برای پروژه‌های بالادستی که از چنین طرح شماره‌گذاری نسخه‌ای استفاده می‌کنند (مانند 1.5a، 1.5b، 1.5c)، دارای یک حرف منفرد در ادامه باشد.

پس از عدد نهایی (و حرف منفرد اختیاری)، ممکن است یک یا چند پسوند اضافه شود که باید یک زیرخط (_) به همراه یکی از موارد alpha، beta، pre، rc، cvs، svn، git، hg یا p باشد، و به‌صورت اختیاری یک عدد دیگر نیز به دنبال آن بیاید. اگر پسوند یکی از مقادیر alpha، beta، pre یا rc باشد، قدیمی‌تر از نسخه بدون این پسوند در نظر گرفته می‌شود؛ اگر پسوند یکی از مقادیر cvs، svn، git، hg یا p باشد، جدیدتر از نسخه بدون این پسوند در نظر گرفته می‌شود. تمامی مثال‌های زیر نسخه‌های معتبر هستند، به ترتیب از کمترین به بیشترین:

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

pkgrel

شماره انتشار بسته برای این نسخه خاص را مشخص می‌کند. این متغیر نشان‌دهنده زمانی است که بسته بدون تغییر در نسخه بالادستی دچار دگرگونی شده است. هر زمان که محتوا، وابستگی‌ها یا متاداده‌های یک بسته را تغییر می‌دهید، همیشه pkgrel را افزایش دهید. نخستین انتشار از یک بسته همواره 0 است.

pkgdesc

مشخص می‌کند که بسته شامل چه مواردی است. مقدار pkgdesc باید ۱۲۸ نویسه یا کمتر باشد و باید به طور موجز توصیف کند که نرم‌افزار یا محتویات بسته‌بندی‌شده به کاربر اجازه انجام چه کارهایی را می‌دهند. برای نمونه، “Fully-featured word processor with spell check and plugins” یک مقدار مناسب برای pkgdesc در برنامه AbiWord خواهد بود.

url

نشانی وب پروژه بالادستی بسته را مشخص می‌کند. این آدرس به کاربران و نگه‌دارندگان آینده امکان می‌دهد مستندات، اطلاعات انتشار و اطلاعات تماس مربوط به بسته را پیدا کنند. اگر هیچ نشانی وبی برای بسته در دسترس نیست، باید url را روی یک رشته خالی ("") تنظیم کنید.

arch

معماری‌هایی را مشخص می‌کند که بسته می‌تواند برای آن‌ها ساخته شود. اکیداً توصیه می‌شود در صورتی که بسته قابل‌حمل (portable) است، این متغیر را روی "all" تنظیم کنید.

در صورتی که بسته حاوی هیچ فایل باینری وابسته به معماری نیست - یعنی فایل‌هایی که فقط برای معماری مقصد کامپایل شده باشند - می‌توانید از "noarch" استفاده کنید. چنین بسته‌هایی ممکن است شامل بسته‌های پایتون خالص، بسته‌های اسکریپت شل و فایل‌های JAR باشند. اگر مطمئن نیستید این موضوع به چه معناست، استفاده از "all" ایمن و بی‌خطر است.

معماری‌ها را می‌توان با استفاده از نویسه ! نفی کرد تا از فهرست معماری‌های پشتیبانی‌شده خارج شوند. به عنوان مثال، arch="all !ppc64le" به این معنی است که بسته اجازه دارد بر روی تمامی معماری‌ها به جز معماری ppc64le ساخته شود.

license

مجوزی که بسته تحت آن توزیع می‌شود را مشخص می‌کند. مقدار ارائه‌شده باید با یک شناسه مجوز SPDX همخوانی داشته باشد.

source

محل فایل‌های سورس محلی و راه دور مورد استفاده برای ساخت بسته را مشخص می‌کند. معمولاً فایل(های) سورس یا آرشیو(های) راه دور مشخص می‌شوند، و در ادامه وصله‌ها (patches) محلی، فایل‌های پیکربندی یا سایر فایل‌های ضروری ذکر می‌گردند.

متغیرهای زیر الزامی نیستند، اما می‌توانند در هر فایل APKBUILD تنظیم شوند.

checkdepends

وابستگی‌های زمان آزمایش (test-time) بسته را مشخص می‌کند. بسته‌های متداولی که برای آزمایش استفاده می‌شوند عبارتند از check، dejagnu و perl-test-command.

depends

وابستگی‌های زمان اجرای (run-time) بسته را مشخص می‌کند. ابزار abuild(1) به طور خودکار بسته نهایی را برای یافتن وابستگی‌های کتابخانه اشتراکی (.so) اسکن می‌کند؛ آن‌ها را در اینجا مشخص نکنید.

install

اسکریپت‌های نصب بسته را، در صورت وجود، مشخص می‌کند. برای اطلاعات بیشتر درباره اسکریپت‌های نصب، بخش اسکریپت‌های نصب را ببینید.

install_if

شرطی را مشخص می‌کند که در صورت برقراری آن، apk(8) باید بسته (یا زیربسته) را به طور خودکار نصب کند. برای نمونه، زیربسته‌های OpenRC این متغیر را به صورت زیر تنظیم می‌کنند: 
install_if="openrc ${subpkgname%-openrc}=$pkgver-r$pkgrel"

که به این معنی است که زیربسته OpenRC به طور خودکار نصب خواهد شد اگر هم OpenRC و هم بسته مبدأ (origin) روی همان سیستم نصب شده باشند.

makedepends

وابستگی‌های زمان ساخت را برای بسته مشخص می‌کند.

maintainer

نام و نشانی ایمیل نگه‌دارنده بسته در قالب RFC 2822. برای نمونه: maintainer="Joe Q. Public <john.q.public@example.com>"

pkggroups

فهرستی از گروه‌های ورود را مشخص می‌کند که با فاصله از هم جدا شده‌اند تا در زمان ساخت ایجاد شوند. توجه داشته باشید که باید گروه‌های ورود را در یک اسکریپت پیش از نصب (pre-install) نیز ایجاد کنید؛ برای اطلاعات بیشتر درباره اسکریپت‌های نصب، بخش اسکریپت‌های نصب را ببینید.

pkgusers

فهرستی از کاربران ورود را مشخص می‌کند که با فاصله از هم جدا شده‌اند تا در زمان ساخت ایجاد شوند. توجه داشته باشید که باید کاربران ورود را در یک اسکریپت پیش از نصب نیز ایجاد کنید؛ برای اطلاعات بیشتر درباره اسکریپت‌های نصب، بخش اسکریپت‌های نصب را ببینید.

provides

مشخص می‌کند که بسته محتوایی مشابه با بسته دیگری را «فراهم» (provides) می‌کند. دو قالب وجود دارد که می‌توانید برای provides استفاده کنید: یک نام فراهم‌کننده، و یک نام فراهم‌کننده به همراه نسخه.

مشخص کردن نام فراهم‌کننده همراه با نسخه مانند foobar=1.2 باعث می‌شود بسته به عنوان یک «نام مستعار» (alias) از foobar نسخه 1.2 عمل کند. در صورتی که کاربر دستوری مانند `apk add foobar` یا مشابه آن را اجرا کند، این بسته به صورت خودکار نصب می‌شود و با بسته‌ای به نام foobar تداخل خواهد داشت.

مشخص کردن نام فراهم‌کننده بدون نسخه مانند baz باعث می‌شود بسته یک فراهم‌کننده «مجازی» به نام baz ارائه دهد. چندین بسته با فراهم‌کننده مجازی یکسان می‌توانند روی یک سیستم نصب شوند؛ با این حال، اگر کاربری دستور `apk add baz` را اجرا کند، فهرستی از بسته‌های ارائه‌دهنده baz به او نمایش داده می‌شود و باید یکی را انتخاب و نصب نماید.

provider_priority

مقدار عددی را مشخص می‌کند که apk(8) هنگام ارزیابی اینکه کدام فراهم‌کننده برای یک ارائه‌دهنده مجازی provides یکسان باید نصب شود، استفاده می‌کند.

replaces

بسته‌هایی را مشخص می‌کند که این بسته جایگزین آن‌ها می‌شود. این مقدار معمولاً برای بسته‌هایی استفاده می‌شود که توسط بالادستی تغییر نام یافته‌اند.

replaces_priority

مقدار عددی مورد استفاده توسط apk(8) را مشخص می‌کند زمانی که چندین بسته دارای replaces شامل فایلی یکسان باشند. این متغیر همچنین برای تصمیم‌گیری در مورد اینکه کدام بسته باید مجوزهای یک دایرکتوری را حتی بدون تنظیم replaces تعیین کند استفاده می‌شود.

subpackages

زیربسته‌ها یا بسته‌های تفکیک‌شده (split packages) ساخته‌شده همراه با این بسته را مشخص می‌کند. معمولاً این مقدار شامل $pkgname-dev برای فایل‌های توسعه (مانند /usr/include و فایل‌های کتابخانه ایستا) و $pkgname-doc برای مستندات (مانند /usr/share/doc و /usr/share/man) است.

به‌طور پیش‌فرض، تابع تفکیک همان بخش پایانی نام بسته پس از آخرین خط تیره است. بنابراین برای $pkgname-foo و libfoo تابع تفکیک به ترتیب foo و libfoo خواهد بود. نام سفارشی تابع تفکیک را می‌توان با استفاده از foo:funcname تعیین کرد. مشابه تابع package، تابع تفکیک باید پس از ایجاد $subpkgdir، فایل‌ها را از $pkgdir (که دایرکتوری کاری پیش‌فرض است) یا $srcdir به $subpkgdir منتقل کند.

به‌طور پیش‌فرض، مقدار arch مشخص می‌کند که آیا یک زیربسته مستقل از معماری در نظر گرفته شود یا خیر. این رفتار را می‌توان با استفاده از foo::noarch یا foo:funcname:all تغییر داد.

هنگامی که چندین زیربسته مشخص می‌شوند، توابع تفکیک آن‌ها به ترتیبی که در subpackages قید شده‌اند اجرا خواهند شد.

triggers

اسکریپت‌های محرک (trigger scripts) مورد استفاده توسط (زیر)بسته‌های مشخص‌شده را تعیین می‌کند. یک اسکریپت محرک، اسکریپتی به زبان شل است که هر زمان فایل‌ها یا دایرکتوری‌های تحت نظارت تغییر یابند، فراخوانی می‌شود. می‌توانید مسیرهای مورد نظر برای نظارت را با استفاده از متغیر triggers به صورت زیر تعیین کنید: 
$pkgname.trigger=/usr/share/man:/usr/local/share/man

این دستور اسکریپت محرک را برای $pkgname هر زمان که فایل‌هایی در /usr/share/man یا /usr/local/share/man ایجاد، اصلاح یا حذف شوند، اجرا خواهد کرد.

options

متغیر options به شما امکان می‌دهد پارامترهایی را برای بسته در زمان ساخت تنظیم کنید. چندین گزینه معتبر وجود دارد که می‌توانید تنظیم نمایید، و می‌توانید چند گزینه را با قرار دادن فاصله میان هر یک از آن‌ها مشخص کنید. نام‌های سفارشی گزینه‌ها زمانی قابل استفاده هستند که دقیقاً شامل یک نویسه : باشند. گزینه‌ها را می‌توان برای یک (زیر)بسته خاص با استفاده از subpkgname::option (یا subpkgname:option برای گزینه‌های سفارشی) تنظیم کرد.

!archcheck

مشخص می‌کند بسته شامل باینری‌هایی است که نمی‌توانند بر روی معماری مقصد اجرا شوند. این گزینه در درجه اول برای بسته‌های حاوی میان‌افزار (firmware) استفاده می‌شود و معمولاً نباید هرگز مورد نیاز باشد.

bigdocs

مشخص می‌کند که این بسته عمداً دارای یک زیربسته doc- بزرگ است. بدین ترتیب، از ارسال هشدار در صورتی که حجم زیربسته doc- از آستانه خاصی (در حال حاضر ۲ مبی‌بایت) فراتر رود جلوگیری می‌کند.

charset.alias

مشخص می‌کند که بسته فایلی با نام /usr/lib/charset.alias به همراه دارد و این فایل باید روی سیستم کاربر نصب شود. این حالت تقریباً هرگز اتفاق نمی‌افتد. از این گزینه استفاده نکنید.

!check

مشخص می‌کند که بسته مجموعه آزمون‌ها را اجرا نخواهد کرد. دلیل غیرفعال‌سازی مرحله بررسی (check) باید در قالب یک کامنت یادداشت شود.

checkroot

مشخص می‌کند که مجموعه آزمون‌های این بسته در fakeroot(8) اجرا خواهد شد. این امر برای برخی مجموعه‌های آزمایشی که اجرای آن‌ها توسط کاربر غیر ریشه با شکست مواجه می‌شود ضروری است.

!dbg

مشخص می‌کند که بسته نباید به همراه یک بسته اطلاعات اشکال‌زدایی (debug) ساخته شود. این حالت پیش‌فرض است مگر اینکه DEFAULT_DBG در متغیرهای محیطی یا در abuild.conf(5) تنظیم شده باشد. این گزینه معمولاً در بسته‌هایی استفاده می‌شود که اطلاعات دیباگ تولید نمی‌کنند (مانند بسته‌های خالص پایتون) یا بسته‌هایی که از بسته‌های اطلاعات دیباگ پشتیبانی نمی‌کنند.

!fhs

مشخص می‌کند که بسته استاندارد FHS را نقض کرده و در مکانی مانند /usr/local، /opt یا /srv نصب می‌شود.

ldpath-recursive

مشخص می‌کند که ابزار abuild(1) هنگام تلاش برای یافتن وابستگی‌های کتابخانه اشتراکی (.so) برای بسته، باید از آرگومان --recursive در scanelf(1) استفاده کند.

lib64

مشخص می‌کند که بسته فایل‌ها را تحت /lib64 یا /usr/lib64 نصب می‌کند و بررسی مربوط به آن دایرکتوری‌ها باید نادیده گرفته شود. این عمل منع شده است و فقط باید برای بسته‌هایی استفاده شود که سازگاری با GNU libc را فراهم می‌کنند.

libtool

مشخص می‌کند که بسته به فایل‌های libtool (.la) خود نیاز دارد. این فایل‌ها به طور خودکار توسط abuild(1) حذف نخواهند شد.

net

مشخص می‌کند که سیستم ساخت بسته نیازمند دسترسی به شبکه است. این اقدام منع شده است و باید یک گزارش مشکل (issue) برای نویسندگان بسته ثبت گردد.

!strip

مشخص می‌کند که نباید دستور strip(1) بر روی هیچ‌یک از باینری‌های بسته اجرا شود. در صورتی که متغیر DEBUG تنظیم شده باشد، این مورد به طور خودکار اعمال می‌شود.

suid

مشخص می‌کند که باینری‌های موجود در بسته ممکن است به صورت set-uid نصب شوند. این یک ریسک امنیتی است و اکیداً توصیه می‌شود در صورت امکان به جای set-uid از قابلیت‌ها (capabilities) یا جداسازی فرایندها استفاده شود.

setcap

مشخص می‌کند باینری‌های بسته ممکن است با قابلیت‌های اضافی setcap(8) نصب شوند. در صورت فعال بودن این گزینه، اکیداً توصیه می‌شود این باینری‌ها فقط توسط ریشه و کاربران یک گروه خاص قابل اجرا باشند، نه توسط دیگران.

textrels

مشخص می‌کند باینری‌های بسته دارای بازنشانی‌ها (relocations) روی بخش‌های متنی هستند. به‌طور پیش‌فرض، abuild(1) از ساخت چنین بسته‌ای خودداری می‌کند چرا که این مورد یک دغدغه امنیتی به شمار می‌رود.

toolchain

مشخص می‌کند که بسته بخشی از مجموعه ابزارهای پایه (base toolchain) است و ممکن است به بسته‌هایی مانند g++ وابسته باشد.

!tracedeps

مشخص می‌کند که abuild(1) نباید به طور خودکار depends و provides را با کتابخانه‌های اشتراکی (.so)، مقاصد پیوندهای نمادین و موارد مشابه پر کند.

متغیرهای زیر توسط abuild(1) برای شما تعریف می‌شوند، اما در صورت لزوم می‌توان مقدار آن‌ها را بازتعریف کرد.

builddir

دایرکتوری محل ساخت کد منبع بسته را مشخص می‌کند. مقدار پیش‌فرض $srcdir/$pkgname-$pkgver است که برای اکثر توزیع‌های کد منبع مناسب است. اگر تاربال سورس پس از استخراج، دایرکتوری $pkgname-$pkgver را ایجاد نمی‌کند، باید builddir را بازتعریف نمایید.

pkgdir

دایرکتوری محل نصب فایل‌های ساخته‌شده را مشخص می‌کند. معمولاً برای نصب فایل‌ها دستور `make DESTDIR="$pkgdir" install` یا مشابه آن را فراخوانی می‌کنید. مقدار پیش‌فرض $startdir/pkg است و نباید این متغیر را تغییر دهید.

srcdir

دایرکتوری محل دانلود و استخراج فایل‌های مشخص‌شده در source را مشخص می‌کند. مقدار پیش‌فرض $startdir/src است و نباید نیازی به تغییر آن داشته باشید.

startdir

دایرکتوری محل استقرار فایل APKBUILD را مشخص می‌کند. معمولاً نباید از این متغیر استفاده شود.

subpkgdir

دایرکتوری محل قرارگیری فایل‌های زیربسته را مشخص می‌کند. این متغیر تنها در داخل توابع زیربسته مقداردهی می‌شود.

متغیرهای زیر تنها در شرایط خاص به کار می‌روند، و بسته به نحوه استفاده و محتوای سایر متغیرها ممکن است الزامی یا اختیاری باشند.

depends_dev

وابستگی‌های زمان اجرای زیربسته -dev.

depends_doc

وابستگی‌های زمان اجرای زیربسته -doc.

depends_libs

وابستگی‌های زمان اجرای زیربسته -libs.

depends_openrc

وابستگی‌های زمان اجرای زیربسته -openrc.

depends_static

وابستگی‌های زمان اجرای زیربسته -static.

depends_systemd

وابستگی‌های زمان اجرای زیربسته -systemd.

depends_udev

وابستگی‌های زمان اجرای زیربسته -udev.

giturl

نشانی اینترنتی (URL) مخزن Git جهت استفاده با دستور `abuild snapshot`. اگر شاخه پیش‌فرض مخزن مد نظر نباشد، می‌توان با افزودن -b branch شاخه دیگری را مشخص کرد که در آن branch همان شاخه‌ای است که باید دریافت (checkout) شود.

توابع مشخص‌شده در اینجا ممکن است در هر فایل APKBUILD حضور داشته باشند، اما به استثنای تابع package، اکیداً الزامی نیستند.

fetch

این تابع برای دانلود فایل‌های راه دور موجود در source فراخوانی می‌شود.

unpack

این تابع تمامی آرشیوهای موجود در source را درون srcdir استخراج می‌کند.

prepare

کد منبع موجود در srcdir را برای ساخت آماده‌سازی می‌کند. تابع پیش‌فرض prepare اطمینان حاصل می‌کند که دایرکتوری‌های ساخت به درستی تنظیم شده‌اند و هرگونه فایل *.patch مشخص‌شده در source را اعمال می‌کند. در صورت نگارش یک تابع سفارشی prepare، باید default_prepare را فراخوانی کنید.

یک تابع سفارشی prepare ممکن است update_config_sub یا update_config_guess را به ترتیب برای به‌روزرسانی فایل‌های config.sub و config.guess فراخوانی کند.

build

کد منبع موجود در builddir را کامپایل می‌کند. شما باید این تابع را خودتان پیاده‌سازی کنید. در صورتی که نیازی به کامپایل نباشد، می‌توانید از آن صرف‌نظر کنید.

check

مجموعه آزمون‌های بسته را اجرا می‌کند. این تابع باید پیاده‌سازی شود مگر اینکه !check در options تعیین شده باشد.

package

بسته را درون pkgdir نصب می‌کند. توجه داشته باشید که pkgdir برای شما ایجاد نمی‌شود؛ اگر این بسته هیچ فایلی نصب نمی‌کند (برای نمونه یک متپکیج)، برای رد شدن از فاز بسته‌بندی باید از `mkdir -p "$pkgdir"` استفاده کنید.

یک اسکریپت نصب زمانی اجرا می‌شود که عملیاتی بر روی بسته توسط apk(8) صورت گیرد. اسکریپت نصب باید به زبان شل نوشته شود و اعلان مفسر #!/bin/sh به عنوان خط نخست آن قرار گیرد. متغیر install باید حاوی اسکریپت‌های نصب مورد نیاز بسته باشد.

اسکریپت نصب درون فایل‌سیستم ریشه‌ای که بسته در آن نصب می‌شود اجرا خواهد شد. یک آرگومان منفرد به اسکریپت‌های فراخوانی ارسال می‌شود که نسخه بسته‌ای است که در حال حاضر نصب (یا حذف) می‌شود. اسکریپت‌های پیش از ارتقا (pre-upgrade) و پس از ارتقا (post-upgrade) یک آرگومان دوم اضافی نیز خواهند داشت که نسخه بسته پیش از فرآیند ارتقا را مشخص می‌کند.

عملیات‌های مختلفی که ممکن است اسکریپت‌های نصب برای آن‌ها مشخص شوند به شرح زیر هستند:

$pkgname.pre-install

پیش از نصب بسته اجرا می‌شود. اگر این اسکریپت با خطا (کد خروج غیر صفر) پایان یابد، apk(8) عملیات نصب را متوقف کرده و بسته نصب نخواهد شد. این اسکریپت نصب معمولاً برای ایجاد کاربران یا گروه‌های مورد نیاز همان‌طور که در pkggroups و pkgusers شرح داده شده به کار می‌رود.

$pkgname.post-install

پس از نصب بسته اجرا می‌شود. اگر این اسکریپت با خطا (کد خروج غیر صفر) خاتمه یابد، apk(8) بسته را به عنوان خراب (broken) علامت‌گذاری می‌کند. در صورت وقوع این حالت، دستور `apk fix` تلاش خواهد کرد اسکریپت post-install را مجدداً اجرا کند.

$pkgname.pre-upgrade

پیش از ارتقای بسته اجرا می‌شود. اگر این اسکریپت با خطا (کد خروج غیر صفر) پایان یابد، apk(8) بسته را به عنوان خراب علامت‌گذاری خواهد کرد.

$pkgname.post-upgrade

پس از ارتقای بسته اجرا می‌شود. اگر این اسکریپت با خطا (کد خروج غیر صفر) خاتمه یابد، apk(8) بسته را به عنوان خراب علامت‌گذاری می‌کند. در صورت وقوع این اتفاق، دستور `apk fix` تلاش خواهد کرد اسکریپت post-upgrade را دوباره اجرا کند.

$pkgname.pre-deinstall

پیش از حذف بسته از سیستم اجرا می‌شود. اگر این اسکریپت با خطا (کد خروج غیر صفر) پایان یابد، apk(8) بسته را از روی سیستم حذف نخواهد کرد.

$pkgname.post-deinstall

پس از حذف بسته از سیستم اجرا می‌شود. خروج همراه با خطا هیچ تأثیری نخواهد داشت.

در حال حاضر، فایل‌های APKBUILD مانند اسکریپت‌های شل معمولی source می‌شوند. این شیوه ممکن است در آینده تغییر یابد.

ابزار abuild(1) به شکلی که توسط Alpine Linux توزیع شده است از شل BusyBox Almquist استفاده می‌کند، بخشی از busybox(1) که در حال حاضر فاقد مستندات است. این شل عمدتاً با استاندارد IEEE Std 1003.2 (“POSIX.2”) و به همراه برخی افزونه‌های شبیه به bash سازگار است. ابزار abuild(1) به شکلی که توسط Adélie توزیع شده است از /bin/sh ترجیحی کاربر استفاده می‌کند که معمولاً bash(1) است.

مرجع مجوز SPDX (در وب در https://spdx.org/licenses)، abuild(1)، newapkbuild(1)، apk(8)، buildrepo(1)، ap(1)، checkapk(1).

قالب APKBUILD و ابزار abuild(1) نخستین بار در Alpine Linux 1.9 پدیدار شدند.

Timo Teräs <timo.teras@iki.fi>
Natanael Copa <ncopa@alpinelinux.org>

مستندات:
A. Wilcox <awilfox@adelielinux.org>

2026-06-05