ความแตกต่างในการจัดการบรรจุภัณฑ์ระหว่าง Debian และ Arch

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

คุณยังสามารถพูดถึงความยืดหยุ่น / พลังงานระหว่างผู้จัดการแพ็คเกจสองคน: อันไหนของทั้งสองช่วยให้คุณทำงานได้มากขึ้น

ฉันทราบว่าคุณลักษณะบางอย่างที่มีอยู่ในระบบการจัดการแพคเกจ Debian จะไม่เกี่ยวข้องกับระบบ Arch เนื่องจาก Arch มีชุดเดียวและ Debian มีหลายอย่าง (เช่นการปักหมุด APT และการจัดการการพึ่งพาขั้นสูงอยู่ในใจ) ดังนั้นโปรดเปรียบเทียบคุณลักษณะต่างๆ ใช้ได้กับทั้งสองระบบ (เช่นสมมติว่าสำหรับ Debian ฉันใช้ไม่เสถียรเท่านั้น)

ฉันใช้ arch เป็นประจำตั้งแต่ไม่กี่สัปดาห์และฉันไม่มีความเชี่ยวชาญในเรื่องดังนั้นคำตอบนี้ไม่ได้ละเอียดถี่ถ้วนเพียงไม่กี่จุดที่ฉันได้กล่าวถึง "ความยืดหยุ่น / พลังงาน":

• นี่เป็นเพียงความประทับใจ แต่ Pacman ดูเหมือนจะทันสมัยและเรียบง่ายในการออกแบบ / สถาปัตยกรรม อย่างน้อยก็มีเครื่องมือที่ใช้จัดการน้อยกว่า ในขณะที่ฉันไม่รู้ซอร์สโค้ดของ apt แต่ฉันเพิ่งดูโค้ด libalpm (ไลบรารี่พื้นฐานของ Pacman) เพื่อทำการปะแก้ที่ง่ายมากและดูเหมือนว่าจะสะอาดและง่ายต่อการเข้าใจ

• นอกจากนี้ยังรวดเร็วมาก (เนื่องจากการเพิ่มประสิทธิภาพและอาจทำได้โดยการดูแลบางสิ่ง (ดูด้านล่าง)) รีลีสล่าสุด (pacman 3.5 อายุสองสามวัน) พยายามปรับปรุงประสิทธิภาพโดยการลดจำนวนไฟล์ฐานข้อมูลที่เกี่ยวข้อง

• แม้ว่า arch จะมุ่งเน้นไปที่การใช้ไบนารีแพ็คเกจ แต่ก็มีข้อดีเมื่อสร้างแพ็คเกจจากแหล่งที่มาพร้อมกับระบบการสร้างที่คล้ายกับพอร์ตของ BSD (ABS)

• มันง่ายและรวดเร็วในการสร้างแพ็คเกจเพียงไม่กี่บรรทัดในไฟล์ PKGBUILD และทำเสร็จแล้วไม่จำเป็นต้องจัดการกับกฎ / กฎ / ลิขสิทธิ์ / การเปลี่ยนแปลง / สิ่งที่ต้องการกับแพ็คเกจ Debian และในไม่กี่คลิกบน web ui แพ็คเกจของคุณจะถูกแชร์กับทุกคนใน AUR (Arch User Repository)

สิ่งที่ฉันได้รับในเดเบียนและไม่อยู่ในซุ้มประตู:

• Triggers / hooks (สิ่งที่ทำให้ apt อัปเดตแคชไอคอน, mandb หรืออะไรก็ได้เพียงแค่ดูที่ไฟล์ติดตั้งแพ็คเกจโดยไม่จำเป็นต้องให้ผู้ทำแพ็กเกจทำอะไร) (ดูเหมือนว่ามีแผนจะใช้สิ่งนี้)

• debconf (ไม่มีเรื่องใหญ่และโดยวิธีการบังคับให้ฉันทำสิ่งต่าง ๆ ด้วยตนเองมันบังคับให้ฉันรู้ว่าสิ่งที่จะทำ) และการจัดการที่เหมาะสมของไฟล์ config ใหม่ (อย่างน้อยฉันอยากจะ Pacman รู้เมื่อไฟล์ config ในแพคเกจใหม่ เวอร์ชันแตกต่างจากรุ่นที่ติดตั้งเนื่องจากมีการเปลี่ยนแปลงในเวอร์ชันใหม่หรือเพราะฉันแก้ไขในเครื่อง)

• การลงนามแพ็คเกจ (ดูเหมือนว่ากำลังใช้งานอยู่ )

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

ฉันเริ่มการเดินทางด้วย Linux กับ Ubuntu ชัดเจนและใช้ Arch ในปัจจุบัน ฉันเขียนแพ็กเกจ Arch จำนวนหนึ่งแล้วฉันจะพูดง่ายกว่าการเขียนแพ็คเกจ Debian แต่ผมอยากจะชี้ให้@gentledevilที่ Arch install fileจะมีระบบตะขอสำหรับแพคเกจที่รู้จักกันเป็น

โดยทั่วไปจะตั้งชื่อ${pkgname}.installและมีฟังก์ชั่นบางอย่างสำหรับการติดตั้ง / ลบ / อัพเกรด / ติดตั้งล่วงหน้า / โพสต์; เพียงแค่วางอัพเดตแคชแบบอักษรของคุณลงไปเรื่อย ๆ และมันก็ทำงานได้เหมือนกับ Debian hooks

นอกจากนี้ฉันสังเกตเห็นว่าคุณพูดถึง 'ปักหมุด' แอปพลิเคชันโดยใช้เครื่องมือจัดการแพคเกจเดเบียน Pacman ของ Arch มีการติดตั้งในตัวเช่นกัน/etc/pacman.confยอมรับการตั้งค่าจำนวนมากรวมถึงIgnorePkg =ซึ่งจะป้องกันการอัปเกรดแพ็คเกจใด ๆ ที่แสดงรายการหลังจากเท่ากับ (เว้นวรรค)

ก่อนที่ฉันจะไปไกลเกินไปศึกษาPictorial Linux Timeline

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

สามผู้ปกครองหลัก

1. Redhat ตอนนี้ Fedora - ตัวจัดการแพ็กเกจ - RPM ย่อมาจาก Redhat Package Manager บรรทัดคำสั่ง rpm
2. Slackware - ตัวจัดการแพ็คเกจ - tgz, ไฟล์ซิปธรรมดา แม้ว่าไฟล์เหล่านี้เป็นเพียงไฟล์ที่ถูกบีบอัด แต่สร้างโดย Slackware upstream และวางไว้ในที่เก็บซึ่งบางครั้งเรียกว่าพอร์ต
3. Debian - DEB ย่อมาจาก Debian มันเป็นเครื่องมือบรรทัดคำสั่งคือ Aptitude or Apt

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

3 ผู้ปกครองผู้เยาว์

1. Linux From Scratch - Source Based ไม่มีตัวจัดการแพ็คเกจ
2. Gentoo - มาจากลินุกซ์จากรอยขีดข่วน การแจกจ่ายนี้เป็นหลักของ Linux จาก Scratch plus ตัวจัดการแพ็คเกจที่เรียกว่า Portage / emerge
3. SourceMage - เวทมนต์ผู้จัดการแพ็กเกจ

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

สะพาน

Arch ถูกสร้างขึ้นเป็นสะพานเชื่อมระหว่างการแจกแจงแบบไบนารีเช่นหนึ่งใน 3 ผู้ปกครองหลักและการกระจายตามแหล่งที่มาเช่นหนึ่งในสามผู้ปกครองรายย่อย ด้วยเหตุนี้จึงได้รับสถานะเป็นพาเรนต์ในไทม์ไลน์เนื่องจากไม่มีพาเรนต์อื่นที่ให้ฟังก์ชันการทำงานนี้ Pacman มีความยืดหยุ่นในการอนุญาตให้ผู้ใช้ติดตั้งแพคเกจไบนารีจากพื้นที่เก็บข้อมูลอย่างเป็นทางการหรือแพคเกจที่สร้างขึ้นเองโดยใช้ระบบ Arch Build แนวคิดนี้ให้ความสมดุลระหว่างพลังที่ผู้ปกครองรายย่อยมอบให้ด้วยความง่ายในการติดตั้งที่ผู้ปกครองรายใหญ่มอบให้

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

• ระดับผู้ใช้: ผู้ที่เพิ่งเริ่มต้นใช้งานลินุกซ์ควรเริ่มต้นด้วยผู้ปกครองหลักในขณะที่บางคนที่มีความเชี่ยวชาญด้านเทคนิคจะพบความสมดุล
• สิ่งที่คุณต้องการทำกับระบบของคุณ: การใช้เซิร์ฟเวอร์ LAMP กับผู้ใช้ที่แนบมานั้นต่างจากการใช้คอมพิวเตอร์ตั้งโต๊ะสำหรับการท่องเว็บและอ่านอีเมล
• ระดับความสะดวกสบาย: ระดับผู้ใช้ที่ไม่อดทนต่อหากคุณมีความเชี่ยวชาญด้านเทคนิค แต่ไม่ต้องการใช้เวลาในการรวบรวมระบบในช่วงสุดสัปดาห์คุณจะต้องเลือกผู้ปกครองรายใหญ่โดยไม่คำนึงว่าทุกคนที่คุณรู้จักเลือกอย่างอื่น

นี่ไม่ใช่คำตอบที่สมบูรณ์หรือครบถ้วนสมบูรณ์ - ผู้โพสต์ก่อนหน้าฉันได้ให้คะแนนดีมากฉันต้องการเพิ่ม 2 เซนต์ของฉัน อีกอย่าง - ฉันไม่เคยชินกับ apt / dpkg เลย ดูเหมือนจะซับซ้อนเกินไปสำหรับฉันฉันรู้สึกสะดวกสบายที่สุดกับ yum / rpm

Pacman นั้นใช้งานง่ายมากซึ่งเป็นมืออาชีพและผู้ควบคุม - คุณสามารถเรียนรู้ที่จะใช้มัน (การสร้างแพ็คเกจกัน) ในบ่ายวันเดียว - มันใช้คุณสมบัติการจัดการแพ็คเกจที่ใช้งานง่ายและสมบูรณ์ แต่ - และนี่เป็นเรื่องใหญ่ แต่ - มันยืดหยุ่นอย่างมาก

หากนักออกแบบไม่ได้คิดถึงคุณสมบัติล่วงหน้าคุณจะถูกทำให้เมา

ตัวอย่างเล็ก ๆ น้อย ๆ : ไม่มีรุ่นดั้งเดิมใน Pacman หากคุณต้องการดาวน์เกรดแพ็คเกจ - คุณต้องดาวน์โหลดรุ่นแพ็คเกจนั้นและใช้ตัวเลือก -U (อัพเกรด) เพื่อติดตั้งจากไฟล์ มันมีความมุ่งมั่นอย่างมากต่อการใช้แพ็คเกจล้ำสมัยบนระบบของคุณเสมอ

ไม่มีการล้างแคชภายใน / การสร้างใหม่ที่สมบูรณ์ หาก (เนื่องจากปัญหาเครือข่าย) การดาวน์โหลดแพคเกจเสียหายเช่นในระหว่าง -Syu ข้อความแสดงข้อผิดพลาดในขณะที่ถูกต้องจะไม่ได้ใช้งานมากนัก - จะไม่ระบุแพ็คเกจที่เสียหายแม้ว่าจะเต็มไปด้วย verbosity และ debug และจำนวน -Syyc จะไม่ทำความสะอาดแคชและดาวน์โหลดแพ็คเกจใหม่ ข่าวดีก็คือ -Sc จะแจ้งให้คุณทราบว่าแพ็กเกจที่ดาวน์โหลดนั้นอยู่ที่ไหนเพื่อให้คุณสามารถลบอันที่ละเมิดออกไปได้ (ถ้าคุณสามารถรู้ได้ว่าอันไหนคือ) หรือพวกมันทั้งหมดแล้วรีสตาร์ท -Syu

การรวม pacman กับ dkms ก็เป็นปัญหาเช่นกัน - ในขณะที่ติดตั้งเคอร์เนลใหม่ฉันยังคงมีข้อผิดพลาดจาก dkms การใช้ dkms build && dkms ติดตั้งกับเคอร์เนลใหม่ที่ทำงานโดยไม่มีข้อผูกมัด pacman จะเสนอข้อมูลใด ๆ ว่าทำไม dkms ล้มเหลวในระหว่างการอัพเกรดเคอร์เนล (ฉันสงสัยว่ามันไม่เคยผ่านเส้นทางที่ถูกต้องของเคอร์เนลใหม่และปล่อยให้ dkms ใช้ค่าเริ่มต้น เคอร์เนล (ปัจจุบันทำงาน) แต่มีเวอร์ชันไม่ถูกต้อง

เรื่องเล็ก ๆ น้อยเกี่ยวกับความยืดหยุ่นของมัน - ตามที่ระบุไว้ฉันคุ้นเคยกับรอบต่อนาที / yum หากฉันมีไฟล์ในระบบของฉันและฉันต้องการที่จะรู้ว่าแพคเกจใดเป็นเจ้าของมันฉันสามารถเรียกใช้ yum ให้ / path / to / file และรับแพคเกจทั้งหมดที่สามารถวางไว้ที่นั่น - แม้ว่าจะไม่มีการติดตั้งใด ๆ หากไฟล์ถูกวางไว้ด้วยตนเองและตอนนี้ฉันต้องการติดตั้งแพคเกจ - มันจะเปลี่ยนใหม่ (เพิ่มนามสกุล. rpmnew) ใหม่และให้ฉันเลือกสิ่งที่จะใช้

pacman เพียงแค่ข้อผิดพลาดออกมาว่าไฟล์มีอยู่แล้ว แต่มีข้อผิดพลาดที่ไม่เกี่ยวข้องอย่างสมบูรณ์ - มันบ่นเรื่องความขัดแย้งระหว่างเจ้าของไฟล์ "true" และแพคเกจ "filesystems" ที่ติดตั้งอยู่ในปัจจุบันราวกับว่ามันเป็นเจ้าของไฟล์เดียวกันด้วย นอกจากนี้ยังมุ่งเน้นไปที่ข้อมูลที่ติดตั้งในท้องถิ่น - การพยายามรับข้อมูล (เช่นรายชื่อไฟล์และความเป็นเจ้าของ) ของแพ็คเกจที่ยังไม่ได้ติดตั้งนั้นใช้งานง่ายกว่า

พูดง่าย ๆ - มันไม่โตเท่า yum และอาจเป็น dpkg ซึ่งให้ความสะดวกในการใช้งานเช่นเดียวกับความไม่ยืดหยุ่นของญาติ