เหตุใดจึงใช้ sbuild บน pbuilder

มีหลายวิธีในการสร้างแพ็คเกจ Debian ในสภาพแวดล้อมที่สะอาดและทำซ้ำได้ สองที่ใช้บ่อยที่สุดคือ pbuilder และ sbuild ส่วนตัวผมใช้ pbuilder เสมอ ฉันพบว่าผู้สร้างใช้งานและบำรุงรักษาง่ายขึ้นมาก ฉันไม่สามารถค้นหาการเปรียบเทียบทั้งสองแบบเคียงข้างกันได้ ฉันพลาดอะไรไป

มีข้อดีอะไรบ้างในการใช้ sbuild บน pbuilder?

sbuild และ pbuilder ได้มีการพัฒนาในช่วงหลายปีที่ผ่านมาเพื่อให้มีฟังก์ชั่นการใช้งานที่เหมือนกันเกือบทั้งหมดและเมื่อคุณสมบัติเพิ่มเข้ามาพวกเขามักจะถูกนำไปใช้อย่างรวดเร็ว

เนื่องจากบรรจุภัณฑ์ Debian เป็นรูปแบบที่ใช้นโยบายเป็นตัวช่วยสำคัญในการพิจารณาว่าปัญหาบิลด์ที่กำหนดนั้นเป็นข้อบกพร่องในการใช้งานตัวสร้างหรือปัญหาเกี่ยวกับแพคเกจที่สร้างขึ้นเพื่อให้มีการใช้งานหลายระบบ เพื่อรักษาสิ่งนี้ระบบสร้างชั้นนำทุกคนจะต้องมีพรรคพวกที่แข็งแกร่งสนับสนุนพวกเขาด้วยจิตวิญญาณของการแข่งขันที่ร่วมมือกันเพื่อให้มั่นใจว่าเรามีการนำนโยบายไปปฏิบัติที่ถูกต้องที่สุด

กลไกภายในของ sbuild และ pbuilder มีความแตกต่างกันอย่างมากดังนั้นแพคเกจที่ถูกดึงเพื่อสร้างความพึงพอใจต่อการสร้างหรือวิธีการดึงกลไกที่แม่นยำซึ่งเป้าหมายต่าง ๆ ในเดเบียน / กฎถูกเรียก ฯลฯ อาจแตกต่างกันเล็กน้อย ความแตกต่างของพฤติกรรมในบางกรณีสำหรับแพ็คเกจบางประเภท ส่วนใหญ่เวลานี้แสดงถึงข้อผิดพลาดในการดำเนินการอย่างใดอย่างหนึ่งและอื่น ๆ และบางครั้งสะท้อนให้เห็นถึงการขาดความชัดเจนในนโยบายบรรจุภัณฑ์: ในกรณีใด ๆ การเปลี่ยนแปลงพฤติกรรมควรได้รับการแก้ไข

บิลด์อย่างเป็นทางการทั้งใน Debian และ Ubuntu ใช้ sbuild (แม้ว่ามักจะไม่ใช่ sbuild ที่มีอยู่ในคลังเก็บ) ซึ่งถือว่าเป็นข้อได้เปรียบจากนักพัฒนาบางคนเนื่องจากพวกเขามีความมั่นใจมากขึ้นว่าการกำหนดค่าของพวกเขาตรงกับที่ แม้ว่าถ้าทุกคนทำสิ่งนี้เราก็สูญเสียความสามารถในการแยกแยะข้อบกพร่องในนโยบายจากข้อบกพร่องในการสร้าง

ในอดีตความเข้าใจของฉันคือการพัฒนา pbuilder เริ่มต้นมุ่งเน้นไปที่ความต้องการของนักพัฒนาในฐานะผู้ใช้ขั้นปลายและการพัฒนา sbuild โดยเริ่มต้นมุ่งเน้นไปที่ความต้องการของผู้ดูแลระบบ buildd และเก็บถาวร เมื่อเร็ว ๆ นี้โฟกัสเหล่านี้ได้เปลี่ยนไปเนื่องจากผู้คนได้สร้างระบบการจัดการการเก็บถาวรตาม pbuilder และเครื่องมือนักพัฒนาที่มีประโยชน์มากขึ้นโดยใช้ sbuild

เครื่องมือทั้งสอง (หรืออนุพันธ์ใกล้ที่มีอยู่ทั่วไป) สนับสนุนการจัดเก็บ chroots เป็น tarballs, unpacked บนระบบในเล่มแยก (พร้อม hooks ที่พร้อมใช้งานสำหรับการติดตั้งพิเศษ: เช่นสแน็ปช็อต LVM) โดยใช้ระบบไฟล์ซ้อนทับ เครื่องมือทั้งสองนำเสนอเครื่องมือบรรทัดคำสั่งเล็กน้อยเพื่อปรับปรุงกรณีทั่วไป (ทดสอบสร้างแพ็คเกจ) และความหมายของ hook hook เพื่อสนับสนุนเคสที่ซับซ้อน (คลังเก็บขนาดใหญ่) ทั้งสองมีวิธีในการสร้างสภาพแวดล้อมการทดสอบใน chroot กล่าวโดยย่อเครื่องมือทั้งสองนี้ให้อะไรก็ได้ที่คุณอาจคิดว่าคุณต้องการในเครื่องมือสร้างแพ็คเกจ

โดยสรุป: หากคุณพอใจกับเครื่องมือสร้างโปรดใช้มันต่อไป หากคุณต้องการเล่นกับ sbuild โปรดรู้สึกฟรี เครื่องมือที่ดีที่สุดคือเครื่องมือที่คุณใช้ในการทำงานที่คุณสะดวก

มันอันตรายเสมอที่จะไม่เห็นด้วยกับ Emmet ดังนั้นให้ฉันเริ่มต้นด้วยการยอมรับว่าคำตอบของเขาอาจจะถูกต้องมากกว่านี้ อย่างไรก็ตามฉันพบว่าผู้ใช้ pbuilder ใช้งานง่ายและมีประสิทธิภาพมากขึ้น

หากคุณอยู่บน Ubuntu 12.10 หรือใหม่กว่าให้แน่ใจว่าได้ติดตั้งสคริปต์ pbuilder ที่ยอดเยี่ยมซึ่งเป็นชุดของตัวห่อหุ้มที่เป็นมิตรอย่างยิ่งเกี่ยวกับตัวสร้างแบบดิบ

หากคุณอยู่ใน Ubuntu 12.04 คุณอาจติดตั้งสคริปต์ pbuilder จากที่เก็บ backports

ตอนนี้เรามาเปรียบเทียบและเปรียบเทียบความแตกต่างที่เป็นมิตรกับผู้ใช้ของการปฏิบัติการที่เทียบเท่ากัน ในตัวอย่างเหล่านี้ฉันจะอธิบายการใช้ ARM chroot ที่โฮสต์บน x86 แต่แนวคิดยังคงมีผลกับ x86 chroot ที่โฮสต์บน x86 เช่นกัน จำไว้ว่าฉันใช้โปรแกรมเสริมสคริปต์ pbuilder

สิ่งหนึ่งที่ควรทราบคือ pbuilder-สคริปต์ใช้การประชุมเล็กน้อยคล้ายกับวิธี Ruby on Rails ที่ทำให้คุณตัดสินใจบางอย่างเพื่อให้คุณสามารถไปได้อย่างรวดเร็ว ฉันจะลองและชี้สิ่งเหล่านี้เมื่อเราไป

สร้าง chroot

mk-sbuild --arch=armhf quantal

VS

# in addition to the chroot, creates a new, empty directory named ~/Projects/quantal-armhf
pcreate -a armhf -d quantal quantal-armhf

verdict: tieทั้งสองบรรทัดคำสั่งนั้นค่อนข้างง่ายและทั้งคู่สามารถใช้ตัวเลือกเพิ่มเติมสำหรับกรณีที่นักเล่นใช้งานได้ถ้าจำเป็น อย่างไรก็ตามอย่าลืมไดเรกทอรีใหม่เพิ่มเติมที่สร้างโดย pcreate

ดาวน์โหลดแพ็คเกจต้นทาง

# standard debian/ubuntu method, works in any directory
apt-get source casper

เมื่อเทียบกับ

# 'quantal-armhf' is the name of the chroot created earlier
# results in downloading package to: ~/Projects/quantal-armhf/casper/
pget quantal-armhf casper

คำตัดสิน: ขอบเล็กน้อยสำหรับ sbuildเพราะคุณใช้แนวปฏิบัติที่ดีที่สุดเดเบียน / อูบุนตู การประชุมที่ใช้โดย pget อาจดูแปลกในตอนแรก แต่เนื่องจากฉันทำงานกับหลายแพ็คเกจใน Ubuntu หลายรุ่นฉันจึงชอบองค์กรที่กำหนดไว้ โปรดทราบว่าแหล่งที่มา apt-get ยังดึงแหล่งที่มาทุกที่ที่คุณเรียกใช้คำสั่งทำให้คุณมี * .orig.tar.gz, * .debian.tar.gz, * .dsc และไดเรกทอรีขยายซึ่งฉันพบว่าเป็นการส่วนตัว เลอะเทอะ ความสวยงามขององค์กรกำลังจะมาถึงในไม่ช้าฉันสัญญา

ป้อน chroot เวอร์ชันชั่วคราว

schroot -c quantal-armhf

เมื่อเทียบกับ

ptest quantal-armhf

คำตัดสิน: ขอบเล็กน้อยสำหรับ pbuildอักขระที่จะพิมพ์น้อยลงคืออักขระที่น้อยลง โปรดทราบว่าในรุ่นนี้ของการป้อน chroot การเปลี่ยนแปลงใด ๆ ที่คุณทำที่นี่จะหายไปเมื่อคุณออกจาก chroot นอกจากนี้โปรดทราบว่าใน schroot คุณจะยังคงเป็นผู้ใช้ปกติในขณะที่ด้วย ptest คุณจะอยู่ใน chroot ในฐานะผู้ใช้รูท

ป้อน chroot บันทึกการเปลี่ยนแปลงเวอร์ชัน

sudo schroot -c quantal-armhf-source -u root

เมื่อเทียบกับ

ptest quantal-armhf --save

คำตัดสิน: ขอบเล็กน้อยสำหรับ pbuildตัวละครน้อยลงและอาร์กิวเมนต์บรรทัดคำสั่งที่ใช้งานง่ายมากขึ้นในความคิดของฉัน ในรุ่นนี้ของการป้อน chroot การเปลี่ยนแปลงใด ๆ ที่คุณทำในนั้นจะถูกบันทึกไว้สำหรับการเรียกใช้ในอนาคต

สร้างแพ็คเกจภายใน chroot

debuild -S -sa -I -i
sbuild -A --arch armhf -d quantal-armhf /path/to/casper-1.315.dsc

เมื่อเทียบกับ

# must be invoked when pwd is ~/Projects/quantal-armhf/casper/casper-1.315
pbuild

คำตัดสิน: pbuildตอนนี้เราเห็นชัยชนะครั้งแรกที่สำคัญเมื่อใช้ระเบียบของ pbuild นี่เป็นคำสั่งแบบง่ายที่ไม่มีอะไรให้จดจำเมื่อเทียบกับการระบุสถาปัตยกรรมชื่อของ chroot และต้องการพา ธ ไปยังไฟล์ * .dsc ที่ sbuild ต้องการ นอกจากนี้คุณต้องอย่าลืมสร้างไฟล์ * .dsc ใหม่ด้วย sbuild ในขณะที่ pbuild จะทำโดยอัตโนมัติสำหรับคุณ

สร้างแพ็คเกจเดียวกันใน chroot ครั้งที่สอง

ในตัวอย่างด้านบนทั้ง sbuild และ pbuild จะดาวน์โหลดและติดตั้ง build-deps ใน chroots ที่เกี่ยวข้อง อย่างไรก็ตาม pbuild จะบันทึกไฟล์. deb ที่ดาวน์โหลดไว้ใน / var ดังนั้นหากคุณเรียกใช้ pbuild เป็นครั้งที่สองคุณไม่จำเป็นต้องดาวน์โหลดบิลด์ทั้งหมดอีกครั้ง (แม้ว่าไฟล์เหล่านั้นจะต้องติดตั้งใน chroot ก็ตาม) sbuild ไม่ได้แคชไฟล์. deb (อย่างน้อยก็ไม่ใช่ตามค่าเริ่มต้น) ดังนั้นคุณต้องดาวน์โหลดบิลด์ทั้งหมดอีกครั้งนอกเหนือจากการรอให้ติดตั้งใน chroot

คำตัดสิน: สร้างโดยยิงนาน การแคช build-deps เป็นการตั้งค่าเริ่มต้นที่ยอดเยี่ยมและ pbuild นั้นฉลาดพอที่จะตรวจสอบว่ามี build-dep เวอร์ชันใหม่กว่าในไฟล์เก็บถาวรและจะดึงเวอร์ชันใหม่ลงหากจำเป็น สำหรับแพ็คเกจที่ซับซ้อนที่มีบิลด์จำนวนมากการตั้งค่าแบบง่าย ๆ นี้จะช่วยให้คุณประหยัดเวลาไม่กี่นาที

สรุป

ออกจากกล่องฉันพบ pbuilder-สคริปต์ที่จะเป็นมิตรและเร็วกว่า sbuild ที่เทียบเท่า แน่นอนมีวิธีที่จะทำให้ pbuilder เร็วขึ้น (สร้างใน tmpfs ปิดการใช้งานบางส่วนของ chroot hooks) และอาจมีเทคนิคเหมือนกันสำหรับการสร้างด้วย แต่ฉันก็ไม่รู้

หวังว่านี่จะช่วยได้