باستخدام Devtools على Arch Linux

• تجميع باستخدام Devtools
• ملفات تكوين Devtools
• المستودع المحلي
• حزمة أسرع

تم إنشاء حزمة Devtools في الأصل للمستخدمين الموثوق بهم لإنشاء حزم للمستودعات الرسمية بشكل صحيح. ومع ذلك ، يمكن استخدامه من قبل المستخدمين العاديين أيضًا لإنشاء حزم AUR ، أو حتى حزم رسمية معدلة.

راجع هذا الدليل لفهم واستخدام AUR بشكل عام ، بما في ذلك الحصول على PKGBUILD. يعرض هذا المستند فقط الخطوات الخاصة بـ Devtools ، إذا كانت هذه هي الطريقة التي تختارها لتجميع الحزمة.

يحافظ Devtools على تثبيت قوس نظيف منفصل ، يقع في /var/lib/archbuild/<TARGET>/root، والذي يحتوي فقط على مجموعات الحزم baseو base-devel. إذا لم يكن هذا التثبيت النظيف موجودًا ، فسيتم إنشاؤه تلقائيًا. إذا كان موجودًا ، فإنه يقوم تلقائيًا بتحديث أي حزم فيه. عند استخدام Devtools في إنشاء حزمة ، يبدأ بنسخة من هذا التثبيت النظيف ، ويثبت الحزم المطلوبة في النسخة فقط ، وينسخ شفرة المصدر فيها ، وينفذ عملية التجميع والتغليف ، وينسخ الحزمة الناتجة فقط ، في شكل متطابق مما هو موجود في المستودعات الرسمية.

هناك مزايا لـ Devtools في التشغيل makepkgمباشرة. ميزة واحدة هي أن base-develالحزم الأخرى اللازمة للترجمة ، ولكن لا تعمل ، الحزمة التي تصنعها لا تنتهي أبدًا في نظامك الرئيسي. هذه حزم أقل يجب ترقيتها بشكل دوري ، ولديها مخاوف بشأنها. على الرغم من كونها فائدة في المقام الأول لمشرفي حزمة القوس ، إلا أن هذه العملية تكشف بسهولة عندما PKGBUILDيكون الخطأ غير صحيح ، على سبيل المثال إذا تم فقد التبعية من القائمة التي تصادف أن المشرف قد قام بتثبيتها بالفعل في نظامهم الرئيسي. يمكنك أيضًا استخدام جهاز أسرع في بناء الحزم ، ونسخ الحزمة الناتجة إلى آلة أبطأ تقوم بتشغيلها ، دون تلويث تركيب آلة المبنى.

العيب الرئيسي هو أن الجذر النظيف موجود دائمًا ، ويأخذ حوالي 800 ميجابايت ، وعادة ما تكون هناك نسخة واحدة هناك مساحة أكبر. لاحظ أنه في حالة /var/lib/archbuild/استخدام Btrfs ، تبدأ نسخة الجذر النظيف في كونها لقطة Btrfs ، بحيث لا تستهلك هذه الملفات ضعف المساحة. يتم الاحتفاظ بالجذر النظيف دائمًا هناك لتجنب إعادة تثبيته في كل مرة يتم فيها تصنيع الحزمة.

تجميع باستخدام Devtools

تثبيت Devtools:

# pacman -S devtools

لبناء حزمة ، يتضمن Devtools archbuild، ولكنك لا تقوم بتشغيل هذا مباشرة. كما يتضمن روابط {extra, gnome-unstable, kde-unstable, staging, testing}-x86_64-build. سيتم فحص الارتباط الرمزي المستخدم لتشغيله archbuild، لتحديد الهدف الذي تريد استخدامه. يمكن تشغيله لاستخدام هذه المستودعات غير المستقرة / المرحلية / التجريبية ، والتي قد تحتوي على إصدارات أحدث من التي تم إصدارها إلى المستودعات الرسمية. لاستخدام المستودعات الرسمية للحزم غير AUR ، في الدليل مع PKGBUILD، على سبيل المثال الدليل الذي تم إنشاؤه git clone، قم بتشغيل ما يلي:

$ extra-x86_64-build

ملحوظة: سوف يشير باقي هذا الدليل ببساطة إلى extra-x86_64-build.

بعد انتهاء التشغيل ، ستكون النتائج التالية:

• /var/lib/archbuild/extra-x86_64/root- chroot نظيف ، وهو التثبيت حتى الآن مع مجموعات الحزم فقط baseو base-devel.
• /var/lib/archbuild/extra-x86_64/<USERNAME>- سيحتوي هذا على جذر البناء . هذه نسخة من chroot النظيف مع أي تبعيات مطلوبة لبناء أو تشغيل الحزمة التي يتم إنشاؤها ، بالإضافة إلى التعليمات البرمجية المصدر ونتائج التجميع والحزمة.
• سيحتوي الدليل الذي أنت فيه على الحزمة وإنشاء ملفات السجل ، بالإضافة إلى أي شفرة مصدر تم تنزيلها.

في النهاية ، قد تلاحظ " Checking PKGBUILD" و " Checking <PKGNAME>-<PKGVER>-<PKGREL>-<ARCH>.pkg.tar.xz". أي أسطر بعد ذلك يتم إخراجها namcap، والتي تبحث تلقائيًا عن مشاكل مثل PKGBUILDالملفات المشوهة ، التبعيات المضمنة التي لا يبدو أن الحزمة تستخدمها ، التبعيات غير المضمنة التي يبدو أن الحزمة تستخدمها ، والمزيد. غالبًا ما يتم إنشاء النتائج الإيجابية الكاذبة namcap، ولكنها أداة رائعة لإعطاء الأشياء للتحقيق. إذا كانت الحزمة الخاصة بك تعمل بشكل صحيح ، فليس من الجيد تنبيه المشرف إلى namcapالإخراج ، إلا إذا كنت قد نظرت فيها وتحققت من إجراء تغيير.

يمكنك استخدامه pacmanلتثبيت الحزمة ، والتي ستقوم بتثبيت أي تبعيات مطلوبة لتشغيل الحزمة طالما أنها في مستودعات رسمية أو مستودع محلي.

إما استخدام مستودع محلي كما هو موضح هنا ، أو تثبيت الملف مباشرة:

# pacman -U <PKGNAME>-<PKGVER>-<PKGREL>-<ARCH>.pkg.tar.xz

إذا كنت extra-x86_64-buildستعمل مرة أخرى ، في الوقت الحالي ، أو في أي وقت لاحق مع هذه الحزمة أو حزمة أخرى ، فستقوم بتحديث chroot النظيف إذا لزم الأمر ، وحذف chroot الإنشاء وجعله نسخة حديثة من chroot النظيف ، وتنفيذ نفس العملية. إذا كان الدليل الخاص بك لا يزال يحتوي على رمز المصدر الذي تم تنزيله من آخر مرة ، فسيستخدمه. إذا كانت الحزمة عبارة عن حزمة AUR التنموية ، فسوف تسحب تغييرات جديدة بدلاً من إعادة استنساخها.

داخليا ، extra-x86_64-buildيعمل makechrootpkg، الذي يستدعي داخليا makepkg. تتضمن خيارات extra-x86_64-buildما يلي:

• -c: تنظيف chroots ، عن طريق إزالة وإعادة إنشاء /var/lib/archbuild/extra-x86_64/الدليل بأكمله ، بما في ذلك chroot النظيفة وجميع بناء الدلائل chroot. نادرًا ما يكون هذا مطلوبًا ، فقط إذا تلف chroot النظيف ، أو إذا تمت ترقية Devtools بطريقة تخرق التوافق العكسي.
• -r <dir>: استخدام دليل مختلف عن /var/lib/archbuild/extra-x86_64/احتواء chroots.

يتم تمرير أي حجج إلى extra-x86_64-buildبعد ، عندما يستخدمها داخليًا. يتم دائمًا تمرير العديد من الحجج تلقائيًا من إلى . هذه الحجج التلقائية . يخبرون بإزالة جذر البناء وجعلها نسخة جديدة من chroot النظيفة ، وتشغيلها على الحزمة إذا تم بناؤها بنجاح. وثمة خيار المستخدمة عادة التي يمكن أن تنتقل إلى هو . هذا هو اسم الدليل لإعطاء جذر البناء ، بدلاً من ذلك ، وهو مفيد للحفاظ على نسخ متعددة أو تجميع حزم متعددة في نفس الوقت.--makechrootpkgextra-x86_64-buildmakechrootpkg-r <value given to extra-x86_64-build -r option if given, /var/lib/archbuild/extra-x86_64 otherwise> -c -nmakechrootpkgnamcapmakechrootpkg-l <copy name><USERNAME>

يتم تمرير أي وسيطات إلى makechrootpkgبعد ، عندما تستخدمه داخليًا لبناء الحزمة. في المرة الأولى التي يتم تشغيلها ، يتم ذلك بخياراته غير القابلة للتغيير ، لتنزيل ملفات المصدر ، إذا لزم الأمر ، وإجراء فحوصات السلامة ؛ وبالتالي لا يمكن إعادة توجيه أي شيء على هذا المدى. يتم تشغيله للمرة الثانية لبناء الحزمة ، ويقوم دائمًا بتمرير الحجج التي تخبر تلقائيًا ، في داخل جذر البناء ، بتثبيت التبعيات المفقودة تلقائيًا المطلوبة لبناء الحزمة واستخدامها ، وليس لطلب التأكيد أثناء التسجيل ، قم بتسجيل عملية الإنشاء إلى نص الملفات بالإضافة إلى ، لا تقم بتحديث التعليمات البرمجية المصدر إذا كان في نظام التحكم في الإصدار ولا تقم بإجراء عمليات التحقق من ملف المصدر.--makepkgmakepkgmakechrootpkgmakepkgmakepkg--syncdeps --noconfirm --log --holdver --skipintegmakepkgpacmanstdout

يمكنك ربطها معًا باستخدام النموذج التالي:

$ extra-x86_64-build <DEVTOOLS-OPTIONS> -- <MAKECHROOTPKG-OPTIONS> -- <MAKEPKG-OPTIONS>

لاحظ أنه /var/lib/archbuildيمكن التعامل معها كما لو كانت دليل مؤقت. إذا كان لديك العديد من محركات الأقراص الثابتة Vultr ، فمن المفيد تحميل نظام ملفات RAID0 (مخطط) هنا. إذا كان لديك الكثير من ذاكرة الوصول العشوائي ، يمكنك أيضًا تثبيت نظام ملفات مدعوم بذاكرة الوصول العشوائي مثل tmpfs. بعد إنشاء الحزمة ، يتم نسخها إلى الدليل الذي قمت بالتشغيل extra-x86_64-buildمنه ، وإذا كنت ترغب في ذلك ، يمكنك في هذه المرحلة الحذف /var/lib/archbuild. ستكون الخطوة التالية أبطأ ، لأنها ستحتاج إلى عمل جذر نظي�� جديد. بدلاً من ذلك ، يمكنك حذف /var/lib/archbuild/<USERNAME>لاستعادة مساحة إضافية من جذر البناء قبل حذفه تلقائيًا بواسطة التشغيل التالي لـ Devtools. لذا ، حتى إذا كان نظام ملفات RAID0 مثبتًا هنا يفشل ، فإن أكثر ما ستفقده هو تجميع في العملية.

ملفات تكوين Devtools

هناك بعض التفاصيل التي يجب ملاحظتها مع ملفات تكوين Devtools. وهي تقع في /usr/share/devtools/، مثل makepkg-x86_64.confو pacman-extra.conf:

• بالنسبة /etcلملفات مثل makepkg.confو pacman.conf، يمكنك تحريرها في مكانها بأمان ، وعندما تتم ترقية الحزمة ، لن يتم استبدال التغييرات الخاصة بك. بل سيحفظ ملفات التكوين الجديدة (إذا تغيرت من الإصدار السابق) التي تنتهي بـ .pacnew. ومع ذلك ، فإن ملفات تكوين Devtools /usr/share/لا يقصد أن يتم تحريرها بواسطة المستخدم ، لذلك عندما تتم ترقية Devtools ، فإنها ستستبدل التغييرات التي قمت بها على هذه الملفات تمامًا دون تنبيهك. تم اقتراح ورفض تغيير هذا السلوك ، لأن هذا يساعد على ضمان إرسال الحزم إلى المستودعات الرسمية جميعها بنفس إعدادات التجميع.
• قيمة MAKEFLAGS، PACKAGERو {SRC,SRCPKG,PKG,LOG}DESTتؤخذ من /etc/makepkg.confبدل /usr/share/devtools/makepkg-x86_64.conf.

المستودع المحلي

إذا كنت تقوم ببناء الحزم التي لها تبعيات على الحزم الأخرى التي قمت ببنائها ، فأنت بحاجة إلى استخدام مستودع محلي ، بحيث pacmanيعثر على التبعيات عند تشغيله داخل جذر البناء.

لإعداد مستودع محلي ، راجع قسم "المستودع المحلي" في هذا الدليل .

إنشاء هدف مخصص:

# ln -s archbuild /usr/bin/custom-x86_64-build
# cp /usr/share/devtools/pacman-{extra,custom}.conf

تحرير /usr/share/devtools/pacman-custom.confوإضافة ما يلي في النهاية:

[archLocalRepo]
SigLevel = Optional TrustAll
Server = file:///archLocalRepo

تحرير /etc/pacman.confوإضافة ما يلي. هذا يفرض ربط الدليل في جهاز chroot:

CacheDir    = /var/cache/pacman/pkg/ /archLocalRepo/

الآن ، بدلاً من extra-x86_64-buildاستخدام هذا:

$ custom-x86_64-build

إذا كنت ترغب دائمًا في استخدام الهدف المخصص ، فيمكنك حذف /var/lib/archbuild/extra-x86_64-build/الدليل إذا كان موجودًا ، حيث سيكون chroots الآن /var/lib/archbuild/custom-x86_64-build/.

حزمة أسرع

لاحظ أن تمكين الحزم المترابطة يتضمن تحرير /usr/share/devtoolsملفات التكوين ، وهو غير مدعوم رسميًا ، لذلك ستحتاج إلى إجراء هذا التغيير في كل مرة يتم فيها ترقية Devtools.

يجمع Devtools حزمة كاملة في تنسيق أرشيف. بشكل افتراضي ، يجعل .tar.xzاستخدام مؤشر ترابط واحد xzللضغط.

في أنظمة وحدة المعالجة المركزية المتعددة ، يمكنك السماح xzباستخدام سلاسل رسائل متعددة من خلال التحرير /usr/share/devtools/makepkg-x86_64.confوتغيير السطر التالي:

COMPRESSXZ=(xz -c -z -)

للسماح بعدد النُسخ التي تمتلكها من النوى الافتراضية:

COMPRESSXZ=(xz -c -z - --threads=0)

للسماح باستخدام نوى افتراضية متعددة ، ولكن ليس كلها ، لتقليل التأثير على الأداء العام للنظام ، قم بإضافة رقم محدد:

COMPRESSXZ=(xz -c -z - --threads=21)

سيؤدي تحديد سلاسل رسائل أكثر من عدد المراكز الافتراضية لديك إلى تقليل الأداء.

إذا كنت لا تمانع في أن يكون حجم ملف الحزمة أكبر (من المحتمل) كثيرًا ، فقم بتعطيل الضغط عن طريق التحرير /usr/share/devtools/makepkg-x86_64.conf، وقم بتغيير السطر التالي:

PKGEXT='.pkg.tar.xz'

قم بتغييره ليبدو كما يلي:

PKGEXT='.pkg.tar'