PKGBUILD

از ArchWiki پارسی
پرش به: ناوبری، جستجو

این مقاله درباره متغیرهای قابل تعریف در یک فایل PKGBUILD بحث می کند. برای اطلاع از توابع PKGBUILD و به طور کلی ساخت بسته ها، به ایجاد بسته‌ها مراجعه کنید.هم چنین،‎man PKGBUILD‎ را بخوانید.

PKGBUILD یک شل اسکریپت است که شامل اطلاعات ساختی که نیازمند بسته های Arch Linux است می باشد.

بسته ها در آرچ لینوکس به کمک ابزار makepkg ساخته می شوند. وقتی makepkg در حال اجراست به دنبال فایل ‎PKGBUILD‎ ی در مسیر جاری می گردد و دستورات داخل فایل را یا جهت کامپایل یا برای به دست آوردن فایل هایی که برای ساخت یک بسته مورد نیاز است ردگیری میکند(pkgname.pkg.tar.xz‎). بسته نهایی شامل فایل های باینری و دستورات نصب است که به آسانی با pacman قابل نصب هستند.

متغیرهای الزامی ‎pkgname‎, ‎pkgver‎, ‎pkgrel‎, ‎arch‎ هستند. ‎license‎ برای ساخت یک بسته چندان الزام آور نیست. اما برای هر PKGBUILDs ای که با دیگران به اشتراک گذاشته می شود توصیه می شود. چنانکه makepkg در صورت نداشتن این متغیر هشداری به شما خواهد داد.

متداول‌تر است تا تعریف متغیرها در PKGBUILD به همان ترتیبی که در زیر آمده است، باشد. با این وجود تا زمانی که سینتکس درست Bash مورد استفاده قرار گیرد در اینمورد اجباری وجود ندارد.

Package name

pkgbase

راهنمایی کلی هنگام ساخت یک بسته ی تکی چنین است که ‎pkgbase‎برای اشاره به گروهی از بسته ها در خروجی دستور makepkg و یا برای نام گذاری بسته هایی که فقط حاوی سورس برنامه هستند استفاده قرار میگیرد. در صورت مشخص نکردن اسم، اولین عنصر از آرایه ‎pkgname‎ مورد استفاده قرار قرار خواهد گرفت. نام متغیر هرگز با دش( -) شروع نمی شود. همه مقادیر برای بسته های مجزا بایستی به صورت global در فایل PKGBUILD تعریف شوند. همه چیز جز متغیرهای #makedepends, #Sources, and #Integrity در تابع ‎package()‎ هر بسته مجزایی قابل سربارگذاری است.


pkgname

نام(های)بسته(ها). این‌ها حروف کوچک الفبا و ارقام شروع می شوند و در ادامه با با کاراکترهای ‎@‎, ‎.‎, ‎_‎, ‎+‎, ‎-‎ کامل میگردند. اسامی اجازه آغاز شدن با دش (-) را ندارند. به دلیل ثبات در کار، ‎pkgname‎ بایستی با نام منبع tarball نرم افزار یکی باشد. به طور مثال اگر نام نرم افزار ‎foobar-2.5.tar.gz‎ است، از ‎pkgname=foobar‎ استفاده کنید. نام دایرکتوری حاوی PKGBUILD نیز باید با نام ‎pkgname‎ یکی باشد.

بسته های مجزا، بایستی به صورت آرایه تعریف شوند. مثلا:‎pkgname=('foo' 'bar')‎

Version

pkgver

نسخه بسته. بایستی همان شماره نسخه ارایه شده توسط نویسنده بسته باشد که می تواند شامل حروف، ارقام، علامت زیر خط(ـ)و یا ترکیبی از این‌ها باشد اما خط فاصله (‎-‎) را شامل نمی شود. در صورتی که نویسنده نرم افزار از این کاراکتر استفاده کرده باشد آنرا با (‎_‎) جایگزین کنید. اگر متغیر ‎pkgver‎ در خطوط بعدی PKGBUILD استفاده شده است، علامت زیر خط(ـ)به راحتی با علامت خط فاصله(-) قابل تعویض است. مثلا:‎source=("$pkgname-${pkgver//_/-}.tar.gz")‎.

توجه: اگر نسخه اصلی نرم افزار از شیوه نسخه گذاری 'برچسب زمانی' مانند ‎30102014‎ استفاده کرده است، شما بایستی از معکوس آن استفاده کنید. مثلا:‎20141030‎ (ISO 8601 format) درغیر این صورت نسخه شما به صورت ورژن جدید نمایش داده نخواهد شد.

pkgrel

شماره انتشار: این مقدار به کاربران اجازه می دهد بین انتشارهای مختلف یک بسته یکسان تمایز قایل شوند؛ هم چون اصلاحات و ویژگی های جدیدتری که به PKGBUILD اضافه میگردند و بسته حاصل تحت تاثیر این تغییرات قرار میگیرد. ‎pkgrel‎ بایستی یک واحد اضافه گردد. وقتی نسخه جدیدی از نرم افزار انتشار می یابد این مقدار به عدد 1 تنظیم می گردد.

epoch

هشدار: ‎epoch‎زمانی استفاده می شود که برای انجام این کار واقعا نیاز باشد.

به این منظور که بسته ها،"اجبارا" به عنوان نسخه جدیدتری از نسخه های پیشین با epoch پایین تر شناخته شوند. این مقدار یک عدد صحیح مثبت است. مقدار پیش فرضش 0 است و زمانی استفاده می شود که روش نسخه گذاری عددی (یا الفبایی) یک بسته تغییر کند یا منطق مقایسه عددی بسته دچار ایراد باشد. به عنوان مثال:

pkgver=5.13
pkgrel=2
epoch=1
1:5.13-2

برای اطلاعات بیشتر در مورد "مقایسه نسخه ها"ببینید:pacman(8)

Generic

pkgdesc

توضیحات هر بسته. توصیه می شود 80 کاراکتر یا کمتر باشد و شامل نام بسته به صورت خود-ارجاعی نباشد. مگر این که application name با package name متفاوت باشند. مثلا:‎pkgdesc="Text editor for X11"‎ به جای ‎pkgdesc="Nedit is a text editor for X11"‎.

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

arch

آرایه ای است از معماری کامپیوترهایی که بسته روی آنها به درستی کار میکند. توزیع آرچ لینوکس به صورت رسمی تنها از معماری های ‎i686‎ و ‎x86_64‎ پشتیبانی میکند. هر چند پروژه هایی نظیر Arch Linux ARM پشتیبانی از دیگر معماری ها هم چون {ic|arm}} را برای armv5 و ‎armv6h‎ را برای armv6 hardfloat و ‎armv7h‎ را برای armv7 hardfloat و ‎aarch64‎ را برای armv8 64bit تدارک دیده اند.

اگر بسته ای در حالت کامپایل شده اش به صورت مستقل از معماری است(شل اسکرپیت ها، فونت ها، تم ها و انواع و اقسام افزونه های دیگر) آنگاه از ‎arch=('any')‎ استفاده کنید. به این نکته توجه کنید که این عبارات بدین خاطر مورد استفاده قرار میگیرد که نشان دهد بسته "یک بار" بیلد می شود و سپس بر روی هر معماری ای قابل استفاده است. این کار سبب خواهد شد که بسته بر خلاف اینکه برچسب های ‎-i686‎, ‎-x86_64‎ رویش خورده شود با عنوان ‎-any‎ برچسب گذاری شود.

اگر معماری بسته ای ایجاب میکند که به جای اینکه روی هر معماری کامپایل شود تنها و تنها یک بار کامپایل گردد، تمامی معماری های رسمی پشتیبانی شده توسط آرچ را برایش ذکر کنید. به عنوان مثال:‎arch=('i686' 'x86_64')‎.

معماری مقصد همواره در طول فرآیند بیلد بوسیله متغیر ‎$CARCH‎ در دسترس است.

url

آدرس url سایت رسمی بسته ای که به صورت packaged درآمده است.

license

نشان دهنده این است که نرم افزار تحت چه مجوزی توزیع شده است. بسته licenses از official repositories حاوی مجوزهای عموما استفاده شده است که در مسیر ‎/usr/share/licenses/common‎ نصب شده است. اگر بسته ای تحت عنوان یکی از مجوزهای زیر پروانه گذاری شده باشد این مقدار باید به نام دایرکتوری ست شود. به عنوان مثال:‎license=('GPL')‎. در صورتی که مشمول مجوز مناسبی نبود کارهای مختلفی باید صورت گیرد:

  1. مقدار ‎custom‎ را به آرایه ‎license‎ اضافه کنید. در صورت تمایل م توانید ‎custom‎ را با ‎custom:name of license جایگزین کنید. هر گاه پروانه ای در بسته های مختلفی از مخازن رسمی مورد استفاده قرار گیرد(از جمله مخزن ‎[community]‎ ) بخشی از licenses بسته خواهد شد.
  1. مجوز را در این مسیر نصب کنید:‎/usr/share/licenses/pkgname/‎ به عنوان نمونه:‎/usr/share/licenses/foobar/LICENSE‎.
  2. در صورتی که مجوز، تنها در یک وب سایت باشد بایستی آنرا به صورت جداگانه در بسته قرار دهید.
  • مجوزهای The BSD یا MIT, zlib/png و [Wikipedia:Python License|Python]]،موارد خاصی هستند و در عنصر licenses بسته نمی توانند قرار داده شوند. به جهت اینکه آرایه ‎license‎ به عنوان مجوز عمومی (‎license=('BSD')‎, ‎license=('MIT')‎, ‎license=('ZLIB')‎ and ‎license=('Python')‎) رفتار میکند. اما از دید تکنیکی، هر کدام یک مجوز اختصاصی هستند. زیرا هر کدام کپی رایت مختص به خود را دارند. هر بسته ای تحت این چهار مجوز، بایستی پروانه مختص خود را در مسیر ‎/usr/share/licenses/pkgname نگهداری کند. بعضی از بسته ها ممکن است تنها با یک مجوز بسته بندی شود. در این موارد ممکن است مدخل های متعددی در آرایه ‎license‎ ساخته شوند. مثلا:‎license=('GPL' 'custom:name of license')‎.
  • (L)GPL نسخه های متعددی دارد.برای نرم افزار تحت (L)GPL قراردادهای زیر وجود دارند:
    • (L)GPL — (L)GPLv2 یا ورژن های بالاتر
    • (L)GPL2 — (L)GPL2 فقط.
    • (L)GPL3 — (L)GPL3 یا هر ورژن بالاتری.
  • اگر پس از تحقیق درباره اینکه هیچ مجوزی نمی توان به نرم افزار داد، PKGBUILD.proto از عنصر ‎unknown‎ استفاده کنید. با این وجود بایستی با تامین کننده بسته تماس گرفته شود و درباره اینکه کدام بخش از نرم افزار و تحت چه شرایطی در دسترس باشد(نباشد) صحبت گردد.
نکته: برخی از نویسندگان نرم افزار، مجوز را به صورت جداگانه ارایه نمی دهند و قوانین را در فایل عمومی مجزایی با نام ‎ReadMe.txt‎ تشریح میکنند. این اطلاعات حین ‎build()‎ بوسیله چیزی شبیه ‎sed -n '/This software/,/ thereof./p' ReadMe.txt > LICENSE‎ قابل استخراج هستند.

groups

group به بسته متعلق است. به عنوان مثال زمانی که بسته kdebase نصب میگردد، تمامی گروه های متعلق به آن بسته نیز نصب خواهد شد.

Dependencies(وابستگی ها)

توجه: آرایه های اضافی متعلق به معماری نرم افزار بوسیله الحاق زیر خط به نام معماری قابل استفاده هستند. مثلا:‎depends_x86_64=()‎, ‎optdepends_x86_64=()‎.

depends(زیر وابستگی ها)

آرایه ای از بسته هایی که قبل از نصب نرم افزار بایستی نصب شوند تا نرم افزار هدف، اجرا گردد. محدودیت در ورژن با عملگر مقایسه قابل پیاده سازی است. مثلا:‎depends=('foobar>=1.8.0')‎ اگر نیاز به محدودیت های چند گانه باشد اعلام نام وابستگی برای هر محدودیت،قابل تکرار است. به عنوان مثال:‎depends=('foobar>=1.8.0' 'foobar<2.0.0')‎.

وابستگی هایی که خود بوسیله وابستگی های دیگر تامین می شوند نیازی به لیست شدن ندارند. مثلا اگر بسته foo به هر دو بسته ی bar و baz وابستگی داشته باشد،و بسته bar به نوبه خود به بسته ی baz وابسته باشد،نیازی به نام بردن بسته baz در آرایه ‎depends‎ متعلق به foo نیست.

optdepends(فرا وابستگی ها)

آرایه ای از بسته هایی که برای کارکرد نرم افزار الزامی نیستند اما ویژگی ها و قابلیت های اضافه تری را فراهم می کنند.این امر ممکن است این مفهوم را برساند که همه ی ویژگی های یک بسته بدون optdepend های مربوطه عمل نخواهند کرد.[۱].اگر نرم افزاری با وابستگی های جایگزین متعددی کار کند،تمامی آنهابه جای آرایه ‎depends‎ می توانند در این متغیر لیست شوند. توضیح مختصری از فعالیت هر فراوابستگی بایستی ذکر گردد.


 optdepends=('cups: printing support'
             'sane: scanners support'
             'libgphoto2: digital cameras support'
             'alsa-lib: sound support'
             'giflib: GIF images support'
             'libjpeg: JPEG images support'
             'libpng: PNG images support')

makedepends

آرایه ای از بسته هایی که تنها برای ساخت نرم افزار موردنیازند. حداقل نسخه وابستگی همانند فرمتی که در آرایه ‎depends‎ هست مشخص می شود.

نکته: کد زیر برای تشخیص اینکه یک بسته یا در گروه base-devel قرار دارد یا توسط یکی از اعضای گروه نصب شده است استفاده می شود:
$ pacman -Si $(pactree -rl package) 2>/dev/null | grep -q "^Groups *:.*base-devel"

checkdepends

آرایه ای از بسته هایی که نرم افزار برای اجرا شدن در محیط تست بدان نیازمند است. اما در زمان اجرا نیازی به آنها نیست. بسته های موجود در این لیست، فرمت مشابهی هم چون ‎depends‎ دارند. این وابستگی ها تنها زمانیکه متد check() لحاظ شود نمایش داده می شوند و قرار است بوسیله makepkg اجرا شود.

توجه: فرض بر این است که گروه نرم افزاری base-devel هنگام ساخت بسته ها با 'makepkg از قبل نصب شده است. اعضای این گروه نباید در آرایه ‎makedepends‎ قرار داده شوند.

Package relations

توجه: آرایه های اضافی متعلق به معماری نرم افزار بوسیله الحاق زیر خط به نام معماری قابل استفاده هستند.مثلا:‎depends_x86_64=()‎, ‎optdepends_x86_64=()‎.

provides

آرایه ای از بسته های اضافی که ویژگی هایی برای نرم افزار به ارمغان می آورد.(یا بسته های مجازی هم چون ‎cron‎ یا ‎sh‎)بسته هایی که آیتم های مشابهی دارند می توانند در کنار هم نصب شوند، مگر اینکه یکی از آنها از آرایه ی ‎conflicts‎ استفاده کرده باشد.

هشدار: نسخه بسته باید ذکر شود(‎pkgver‎ و شاید ‎pkgrel‎)اگر بسته ها، نیاز به یکی از این نرم افزارها داشته باشند. به عنوان مثال، نسخه تغییر یافته بسته qt ورژن 3.3.8،با نام qt-foobar باید از ‎provides=('qt=3.3.8')‎ استفاده کند. استفاده از ‎provides=('qt')‎ سبب می شود وابستگی های مورد نیاز یک نسخه به خصوص qt شکست بخورند. ‎pkgname‎ را به آرایه ‎provides‎ اضافه نکنید. چون به صورت خودکار انجام می شود.

conflicts

آرایه ای از بسته هایی که در صورت نصب، باعث بروز تداخل یا مشکل با بسته می شوند. تمامی این بسته ها و تامین کنندگانشان بایستی حذف شوند. ویژگی های نسخه ی بسته های دارای تداخل به همان صورتی که در آرایه ‎depends‎ وجود دارند مشخص می شوند.


replaces

آرایه ای از بسته های منسوخی که بوسیله بسته جایگزین شده اند. مثلا:wireshark-gtk از ‎replaces=('wireshark')‎ استفاده می کند. در زمان همگام سازی، pacman در مواجهه با متغیر ‎replaces‎ سریعا بسته نصب شده را بسته مخازن جایگزین میکند. در صورت استفاده از نسخه جایگزینی از بسته جاری یا آپلود از AUR، از آرایه های ‎conflicts‎ و ‎provides‎ استفاده کنید که تنها زمانیکه بسته های دارای تداخل نصب باشند، عمل میکنند.

Others

backup

آرایه ای از فایل هایی که حاوی تغییرات کاربر است و باید در طول ارتقا یا حذف بسته حفظ شوند. در درجه اول برای تنظمیات فایل ها در مسیر {ic|/etc}} قرارداده شده است. فایل ها در این آرایه بایستی از مسیرهای نسبی بدون (‎/‎) استفاده کنند. (مثلا:{ic|etc/pacman.conf}} به جای {ic|/etc/pacman.conf}}).

هنگام به روزرسانی، نسخه های جدید ممکن است در مسیر ‎file.pacnew‎ برای جلوگیری از دوباره نویسی فایل موجودی که قبلا توسط کاربر اصلاح شده اند، ذخیره شوند. مشابها، هنگام حذف بسته، فایل های اصلاح شده توسط کاربر، با عنوان ‎file.pacsave‎ حفظ خواهند شد؛ مگر اینکه بسته با دستور ‎pacman -Rn‎ حذف شده باشد.

برای اطلاعات بیشتر ببینید:Pacnew and Pacsave files.

options

این آرایه، اجازه سربارگذاری برخی از رفتارهای پیش فرض makepkg را که در مسیر ‎/etc/makepkg.conf‎ قرار دارد میدهد. برای ست کردن این گزینه، نام را در آرایه وارد کنید. برای بازگشت به رفتار پیش فرض، ‎!‎ را در جلویش قرار دهید.

لیست کاملی از گزینه های موجود در PKGBUILD(5) موجود است.

install

اگر اسکرپیت ‎.install‎ موجود باشد باید نام آن در PKGBUILD آورده‌شود. این نام دقیقا همانی است که مساوی ‎pkgname‎ است. هنگام نصب، حذف یا ارتقا یک بسته، pacman قادر است اسکریپت های مختص به بسته را نگهداری و اجرا کند. اسکریپت شامل توابع زیر است که در زمان های مختلفی اجرا میگردند.

  • ‎pre_install‎ — این اسکریپت دقیقا قبل از استخراج فایل ها اجرا می شود. یک آرگومان به این متد پاس داده می شود:new package version.
  • ‎post_install‎ — این اسکریپت دقیقا پس از استخراج فایل ها اجرا می شود. یک آرگومان به این متد پاس داده می شود:new package version.
  • ‎pre_upgrade‎ — این اسکریپت دقیقا قبل از استخراج فایل ها اجرا می شود. دو آرگومان به این متد پاس داده می شود:new package version و old package version.
  • ‎post_upgrade‎ — این اسکریپت دقیقا پس از استخراج فایل ها اجرا می شود. دو آرگومان به این متد پاس داده می شود:new package version و old package version.
  • ‎pre_remove‎ — این اسکریپت دقیقا قبل از حذف فایل ها اجرا می شود. یک آرگومان به این متد پاس داده می شود:old package version.
  • ‎post_remove‎ — این اسکریپت دقیقا پس از حذف فایل ها اجرا می شود. یک آرگومان به این متد پاس داده می شود:old package version.

هر متدی داخل دایرکتوری نصب pacman اجرا میگردند. chrootببینید:https://bbs.archlinux.org/viewtopic.php?pid=913891 this thread].

نکته: نمونه ای از ‎.install‎ در /usr/share/pacman/proto.install.
موجود است.

changelog

نام لاگ تغییر بسته. برای مشاهده تغییرات بسته های نصب شده:(که حاوی این فایل است)


 $ pacman -Qc ''pkgname''

Sources

source

توجه: آرایه های اضافی متعلق به معماری نرم افزار بوسیله الحاق زیر خط به نام معماری قابل استفاده هستند. مثلا:‎depends_x86_64=()‎, ‎optdepends_x86_64=()‎بایستی درستی متناظری بین آرایه ها و checksums ها وجود داشته باشد. مثلا:‎sha256sums_x86_64=()‎.

آرایه ای از فایل هایی که برای ساخت بسته مورد نیازند. بایستی شامل محل فیزیکی سورس نرم افزار باشد که در اکثر موارد یک آدرس HTTP یا FTP کامل است. متغیرهای قبلا ست شده ی ‎pkgname‎ و ‎pkgver‎ نیز به طرز موثری در اینجا قابل استفاده اند. (مثلا:‎source=("https://example.com/$pkgname-$pkgver.tar.gz")‎)

فایل ها می توانند به طور مستقیم در در محل ‎PKGBUILD‎ تولید و به این آرایه افزوده شوند. این مسیر ها، نسبت به دایرکتوری ‎PKGBUILD‎ تفسیر می شوند. قبل از شروع واقعی فرآيند ساخت بسته، تمامی فایل هایی که در این آرایه، آدرس دهی شده اند برای دانلود یا بررسی موجود بودن تست می شوند و اگر هر فقدانی در وجود بسته ها وجود داشته باشد makepkg ادامه نخواهد داد.

توجه: فایل های .install نباید قرار داده شوند.
نکته: نام منبع جایگزین برای فایل های دانلود شده با این سینتکس ‎source=('filename::fileuri')‎ تعیین می شود:
source=("project_name::hg+https://googlefontdirectory.googlecode.com/hg/")

فایل هایی که در آرایه منبع با پسوند .sig, .sign, .asc موجودند، توسط makepkg به عنوان امضای PGP شناخته می شوند و به صورت اتوماتیک برای بررسی درستی منبع-فایل های متناظر استفاده می شوند.

noextract

آرایه ای از فایل های لیست شده در ‎source‎ که نباید توسط makepkg از حالت آرشیو شده خود استخراج شوند. این عنصر با آرشیوهایی که بوسیله ‎/usr/bin/bsdtar‎ مدیریت نمی شوند استفاده می شود یا برای آنهایی که باید همان گونه که هستندنصب شوند. اگر ابزار unarchive کننده جایگزینی استفاده شود. (به عنوان مثال:lrzip)بایستی در آرایه ‎makedepends‎ اضافه گردد و اولین خط از متد prepare() منبع آرشیو شده را باید به صورت دستی استخراج کند. مثلا:

prepare() {
   lrzip -d source.tar.lrz
}

توجه داشته باشید در حالی که آرایه ‎source‎ آدرس های URLs را می پذیرد، ‎noextract‎ تنها بخش نام را.

source=("http://foo.org/bar/foobar.tar.xz")
noextract=('foobar.tar.xz')

برای استخراج nothing، شما باید کاری شبیه این کنید:(برگرفته از firefox-i18n's PKGBUILD):

noextract=("${source[@]%%::*}")

validpgpkeys

آرایه ای از اثر انگشت های PGP. در صورت استفاده، makepkg تنها، امضای کلیدهای لیست شده در اینجا را می پذیرد و از مقادیر معتبر دسته کلید چشم پوشی می‌کند. اگر فایل منبع با کلیدی امضا شده باشد، makepkg هم چنان از کلید اصلی برای مقایسه استفاده می‌کند. تنها، اثر انگشت های کامل پذیرفته می شوند. آنها بایستی با حروف بزرگ و بدون کاراکتر خط فاصله باشند.

توجه: برای تشخیص کلید مناسب هر اثر انگشت از ‎gpg --list-keys --fingerprint <KEYID>‎ استفاده کنید.

Integrity

این متغیرها آرایه هایی هستند که آیتم هایشان رشته های کنترلی ست و برای بررسی درستی فایل های مربوطه در آرایه ی source مورد استفاده قرار می‌گیرند. می توانید ‎SKIP‎ را برای یک فایل مشخص درج کنید و با این کار checksum آن تست نخواهد شد.

چک سام ها، برای بررسی تمامیت و درستیفایل های دانلود شده هستند نه برای 'صحت و اعتبارآنها. به همین دلیل با اینکه الگوریتم MD5 هنگام استفاده برای مقاصد دیگر، آسیب پذیری های قابل ملاحظه ای دارد ،برای بررسی درستی و تمامیت فایلها به عنوان جایگزین سریعتری از هش های SHA-2 توصبه می شود. به‌خصوص زمانی که فایل های بزرگتری در آرایه ‎source‎ وجود دارند. در صورت امکان، بهر حال، همواره صحت و اعتبار فایل ها را با اضافه کردن امضایشان به آرایه ‎source‎ تست کنید: دراین مورد همان طور که در بالا شرح داده شد، شما قادرید بدون خطر از مرحله تایید چک سام عبور کنید.

مقادیر این متغیرها بوسیله گزینه ‎-g‎/‎--geninteg‎ از makepkg طور اتوماتیک ساخته می شوند پس از پیوست عمومی با ‎makepkg -g >> PKGBUILD‎. دستور ‎updpkgsums‎ قادر است متغیر هارا در هر کجای PKGBUILD به روز رسانی کند. هر دو ابزار از متغیرهایی که قبلا در PKGBUILD ست شده اند استفاده می‌کنند و در صورتی که متغیری ست نشده باشد به ‎md5sums‎ بر‌میگردد. چک کردن درستی و تمامیت فایل بوسیله گزینه ‎INTEGRITY_CHECK‎ که در ‎/etc/makepkg.conf‎ وجود دارد، امکان پذیر است. ببینید:makepkg.conf(5).

md5sums

آرایه 128 بیتی چک سام های MD5 مربوط به فایل های لیست شده در آرایه ‎source‎.

sha1sums

آرایه 160 بیتی چک سام های SHA-1 مربوط به فایل های لیست شده در آرایه ‎source‎.


sha256sums

آرایه چک سام های SHA-2 با سایز خلاصه شده 256 بیت.

sha224sums, sha384sums, sha512sums

آرایه ای از چک سام های SHA-2 به ترتیب با سایزهای خلاصه شده 224, 384, 512 بیت. جایگزین های عمومی کمتری برای ‎sha256sums‎ وجود دارند.

هم چنین ببینید