การใช้ Devtools บน Arch Linux

• รวบรวมโดยใช้ Devtools
• ไฟล์การกำหนดค่า Devtools
• ที่เก็บในเครื่อง
• แพ็คเกจเร็วขึ้น

เดิมแพ็คเกจ Devtools สร้างขึ้นสำหรับผู้ใช้ที่เชื่อถือได้เพื่อสร้างแพ็คเกจสำหรับที่เก็บอย่างเป็นทางการ อย่างไรก็ตามผู้ใช้ทั่วไปสามารถใช้แพ็คเกจนี้เพื่อสร้างแพ็คเกจ AUR หรือแม้แต่แพ็คเกจอย่างเป็นทางการ

อ้างถึงคำแนะนำนี้สำหรับการทำความเข้าใจและการใช้ AUR PKGBUILDโดยทั่วไปรวมทั้งการได้รับ เอกสารนี้จะแสดงขั้นตอนเฉพาะสำหรับ Devtools หากเป็นวิธีที่คุณเลือกในการรวบรวมแพ็คเกจ

Devtools รักษาติดตั้งแยกต่างหากสะอาด Arch ตั้งอยู่ใน/var/lib/archbuild/<TARGET>/rootซึ่งมีเพียงกลุ่มแพคเกจและbase base-develหากไม่มีการติดตั้งใหม่ทั้งหมดจะเป็นการสร้างขึ้นโดยอัตโนมัติ หากมีอยู่มันจะอัพเดตแพ็คเกจใด ๆ โดยอัตโนมัติ เมื่อ Devtools ถูกใช้เพื่อสร้างแพ็คเกจมันจะเริ่มต้นด้วยสำเนาของการติดตั้งใหม่ทั้งหมดติดตั้งแพ็คเกจที่จำเป็นลงในการคัดลอกเท่านั้นคัดลอกซอร์สโค้ดลงในนั้นทำการรวบรวมและบรรจุในนั้นและคัดลอกแพ็กเกจผลลัพธ์เท่านั้น ในรูปแบบที่เหมือนกันจากสิ่งที่พบในที่เก็บอย่างเป็นทางการ

มีข้อดีที่ Devtools ทำงานมากกว่าmakepkgโดยตรง ข้อดีอย่างหนึ่งคือbase-develแพคเกจอื่น ๆ ที่จำเป็นในการรวบรวม แต่ไม่ได้ใช้งานแพ็กเกจที่คุณสร้างขึ้นไม่เคยจบลงในระบบหลักของคุณ นั่นเป็นแพ็คเกจที่น้อยกว่าที่จะต้องอัพเกรดเป็นระยะและมีความกังวลเกี่ยวกับ แม้ว่าประโยชน์หลักสำหรับผู้ดูแลแพคเกจ Arch กระบวนการนี้จะเปิดเผยได้อย่างง่ายดายเมื่อ a PKGBUILDไม่ถูกต้องเช่นถ้าไม่ได้ขึ้นต่อกันจากการแสดงรายการว่าผู้ดูแลติดตั้งเกิดขึ้นแล้วในระบบหลักของพวกเขา นอกจากนี้คุณยังสามารถใช้เครื่องที่เร็วกว่าในการสร้างแพ็คเกจและคัดลอกแพ็กเกจผลลัพธ์ไปยังเครื่องที่ช้ากว่าที่จะรันโดยไม่สร้างมลพิษให้กับการติดตั้งของเครื่องสร้าง

ข้อเสียเปรียบหลักคือรูทที่สะอาดอยู่ที่นั่นเสมอโดยใช้เวลาประมาณ 800MB และโดยปกติแล้วการคัดลอกครั้งเดียวจะมีพื้นที่มากขึ้น หมายเหตุถ้า/var/lib/archbuild/ใช้ Btrfs สำเนาของรากที่สะอาดจะเริ่มต้นเป็นสแน็ปช็อต Btrfs ดังนั้นไฟล์เหล่านั้นจะไม่เพิ่มพื้นที่ว่างเป็นสองเท่า รากที่สะอาดจะถูกเก็บไว้ที่นั่นเสมอเพื่อหลีกเลี่ยงการติดตั้งใหม่ทุกครั้งที่มีการสร้างแพ็คเกจ

รวบรวมโดยใช้ Devtools

ติดตั้ง Devtools:

# pacman -S devtools

ในการสร้างแพ็คเกจ Devtools มีarchbuildแต่คุณไม่ได้รันสิ่งนี้โดยตรง นอกจากนี้ยังมี symlinks {extra, gnome-unstable, kde-unstable, staging, testing}-x86_64-buildของ symlink กำลังถูกใช้เพื่อรันมันจะถูกตรวจสอบโดยarchbuildเพื่อกำหนดเป้าหมายที่คุณต้องการใช้ สามารถรันเพื่อใช้ที่เก็บข้อมูลที่ไม่แน่นอน / การจัดเตรียม / การทดสอบเหล่านี้ซึ่งอาจมีเวอร์ชันที่ใหม่กว่าที่เผยแพร่ไปยังที่เก็บอย่างเป็นทางการ หากต้องการใช้ที่เก็บอย่างเป็นทางการสำหรับแพ็กเกจที่ไม่ใช่ AUR ในไดเร็กทอรีที่มีPKGBUILDตัวอย่างเช่นไดเร็กทอรีที่ทำโดยgit cloneให้รันดังต่อไปนี้:

$ extra-x86_64-build

หมายเหตุ: ส่วนที่เหลือของคู่มือนี้ก็จะหมายถึงextra-x86_64-build

หลังจากเสร็จสิ้นการทำงานต่อไปนี้จะเป็นผลลัพธ์:

• /var/lib/archbuild/extra-x86_64/root- เป็นchroot สะอาดซึ่งเป็นถึงวันที่ติดตั้งกับกลุ่มแพคเกจเท่านั้นและbasebase-devel
• /var/lib/archbuild/extra-x86_64/<USERNAME>- นี้จะมีการสร้าง chroot นี่เป็นสำเนาของคลีน chroot ที่มีการขึ้นต่อกันใด ๆ ที่จำเป็นในการสร้างหรือเรียกใช้แพ็คเกจที่กำลังสร้างรวมถึงซอร์สโค้ดผลการรวบรวมและแพ็คเกจ
• ไดเรกทอรีที่คุณอยู่จะมีแพ็คเกจและสร้างไฟล์บันทึกรวมถึงซอร์สโค้ดที่ดาวน์โหลดมา

ในตอนท้ายคุณอาจสังเกตเห็น " Checking PKGBUILD" และ " Checking <PKGNAME>-<PKGVER>-<PKGREL>-<ARCH>.pkg.tar.xz" บรรทัดใด ๆ หลังจากสิ่งเหล่านี้เป็นผลลัพธ์จากnamcapซึ่งจะค้นหาปัญหาโดยอัตโนมัติเช่นPKGBUILDไฟล์ที่มีรูปแบบไม่ถูกต้องการพึ่งพารวมถึงแพ็กเกจที่ไม่ปรากฏว่าใช้งานการอ้างอิงไม่รวมแพ็กเกจที่ดูเหมือนจะใช้และอื่น ๆ ผลบวกปลอมมักถูกสร้างขึ้นnamcapแต่เป็นเครื่องมือที่ยอดเยี่ยมสำหรับการให้สิ่งต่าง ๆ ในการตรวจสอบ หากแพคเกจของคุณทำงานอย่างถูกต้องคุณไม่ควรแจ้งเตือนผู้ดูแลnamcapผลงานจนกว่าคุณจะตรวจสอบและยืนยันว่าควรทำการเปลี่ยนแปลง

คุณสามารถใช้pacmanเพื่อติดตั้งแพคเกจซึ่งจะติดตั้งการพึ่งพาใด ๆ ที่จำเป็นในการเรียกใช้แพคเกจตราบเท่าที่พวกเขาอยู่ในที่เก็บอย่างเป็นทางการหรือที่เก็บในพื้นที่

ใช้ Local Repository ตามที่อธิบายไว้ที่นี่หรือติดตั้งไฟล์โดยตรง:

# 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/ไดเรกทอรีทั้งหมดใหม่รวมถึง clean chroot และไดเรกทอรี build chroot ทั้งหมด สิ่งนี้ไม่ค่อยมีความจำเป็นเฉพาะในกรณีที่ chroot ที่สะอาดได้รับความเสียหายหรือหาก Devtools ได้รับการอัพเกรดในลักษณะที่เข้ากันไม่ได้
• -r <dir>: ใช้ไดเรกทอรีอื่นที่ไม่ใช่/var/lib/archbuild/extra-x86_64/chroots

อาร์กิวเมนต์ใด ๆ ที่เป็นextra-x86_64-buildafter --จะถูกส่งผ่านไปmakechrootpkgเมื่อมันใช้เป็นการภายใน หลายข้อโต้แย้งมักจะผ่านไปโดยอัตโนมัติจากไปextra-x86_64-build ข้อโต้แย้งเหล่านี้เป็นไปโดยอัตโนมัติmakechrootpkg -r <value given to extra-x86_64-build -r option if given, /var/lib/archbuild/extra-x86_64 otherwise> -c -nพวกเขาบอกmakechrootpkgให้ลบ build chroot และทำให้มันเป็นสำเนาใหม่ของ clean chroot และเรียกใช้namcapบนแพ็คเกจถ้ามันสร้างสำเร็จ ตัวเลือกที่ใช้กันทั่วไปที่สามารถส่งผ่านไปยังมีmakechrootpkg -l <copy name>นี่คือชื่อไดเร็กทอรีเพื่อให้บิลด์ chroot แทนที่จะ<USERNAME>เป็นประโยชน์สำหรับการบำรุงรักษาสำเนาหลายชุดหรือรวบรวมหลายแพ็คเกจในเวลาเดียวกัน

ข้อโต้แย้งใด ๆ ที่เกิดขึ้นmakechrootpkgหลังจากนั้น--จะถูกส่งผ่านไปmakepkgเมื่อมันใช้เป็นการภายในเพื่อสร้างแพ็คเกจ ครั้งแรกที่makepkgดำเนินการโดยmakechrootpkgจะทำด้วยตัวเลือกที่ไม่สามารถเปลี่ยนแปลงได้ของตัวเองเพื่อดาวน์โหลดไฟล์ต้นฉบับหากจำเป็นและทำการตรวจสอบความสมบูรณ์ ดังนั้นจึงไม่มีอะไรสามารถส่งต่อในการเรียกใช้ มันวิ่งmakepkgเป็นครั้งที่สองในการสร้างแพคเกจและเสมอโดยอัตโนมัติผ่านmakepkgการขัดแย้งของ--syncdeps --noconfirm --log --holdver --skipintegที่บอกmakepkgไปในการสร้าง chroot ติดตั้งโดยอัตโนมัติอ้างอิงที่จำเป็นสำหรับการสร้างและการใช้แพคเกจที่หายไปไม่ได้ที่จะขอคำยืนยันในระหว่างการpacmanเข้าสู่ระบบสร้างกระบวนการให้กับข้อความ ไฟล์ที่นอกเหนือจากstdoutนั้นอย่าอัปเดตซอร์สโค้ดหากในระบบควบคุมเวอร์ชันและไม่ทำการตรวจสอบการตรวจสอบไฟล์ต้นฉบับ

คุณสามารถโยงมันเข้าด้วยกันโดยใช้แบบฟอร์มต่อไปนี้:

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

โปรดทราบว่า/var/lib/archbuildสามารถปฏิบัติเสมือนว่าเป็นไดเรกทอรีชั่วคราว หากคุณมีฮาร์ดไดรฟ์ Vultr หลายตัวมันก็คุ้มค่าที่จะติดตั้งระบบไฟล์ RAID0 (สตริป) ที่นี่ หากคุณมี RAM จำนวนมากคุณสามารถติดตั้งระบบไฟล์ที่สำรองข้อมูลด้วยเช่นtmpfsกัน หลังจากสร้างแพ็คเกจแล้วมันจะถูกคัดลอกไปยังไดเรกทอรีที่คุณเรียกใช้extra-x86_64-buildและถ้าคุณต้องการ ณ จุดนี้คุณสามารถลบ/var/lib/archbuildได้ การเรียกใช้ครั้งต่อไปจะช้าลงเพราะจะต้องสร้างรากใหม่ที่สะอาด หรือคุณสามารถลบ/var/lib/archbuild/<USERNAME>เพื่อเรียกคืนพื้นที่พิเศษจากบิลด์ chroot ก่อนที่มันจะถูกลบโดยอัตโนมัติโดยการเรียกใช้ 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ทำงานภายในบิลด์ chroot มันจะค้นหาการพึ่งพา

หากต้องการตั้งค่าที่เก็บข้อมูลในพื้นที่ให้อ้างอิงส่วน "คลังพื้นที่" ของคู่มือนี้

สร้างเป้าหมายที่กำหนดเอง:

# 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บีบอัด

บนระบบหลาย CPU คุณสามารถอนุญาตให้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'