ข้อดี / ข้อเสียของ deb เทียบกับรอบต่อนาทีคืออะไร

ไม่ว่าด้วยเหตุผลใดฉันจะใช้การแจกแจงตาม RPM เสมอ (Fedora, Centos และ openSUSE ปัจจุบัน) ฉันเคยได้ยินมาบ่อยครั้งว่า deb นั้นดีกว่า rpm แต่เมื่อถูกถามว่าทำไมไม่เคยได้รับคำตอบที่สอดคล้องกัน (มักจะได้รับการพูดจาอิจฉา

ฉันเข้าใจว่าอาจมีเหตุผลทางประวัติศาสตร์ แต่สำหรับการแจกแจงสมัยใหม่โดยใช้วิธีการบรรจุภัณฑ์ที่แตกต่างกันสองคนใครสามารถให้ข้อดีทางเทคนิค (หรืออื่น ๆ ) ของหนึ่งเทียบกับคนอื่น ๆ ?

ความแตกต่างหลักสำหรับผู้ดูแลแพคเกจ (ฉันคิดว่าจะเป็น 'นักพัฒนา' ใน Debian lingo) เป็นวิธีที่ meta-data แพ็คเกจและสคริปต์ที่มาพร้อมกันมารวมกัน

ในโลก RPM ทุกแพคเกจของคุณ (RPM ที่คุณรักษา) ~/rpmbuildตั้งอยู่ในสิ่งที่ต้องการ ข้างใต้มีSPECไดเร็กทอรีสำหรับไฟล์ spec ของคุณ, SOURCESไดเร็กทอรีสำหรับ tarballs ต้นทางRPMSและSRPMSไดเร็กทอรีเพื่อวาง RPMs และ SRPMs ที่สร้างขึ้นใหม่และสิ่งอื่น ๆ ที่ไม่เกี่ยวข้องในตอนนี้

ทุกสิ่งที่เกี่ยวข้องกับวิธีการสร้าง RPM อยู่ในไฟล์ข้อมูลจำเพาะ: สิ่งที่แพตช์จะถูกนำไปใช้, สคริปต์ก่อนและหลัง, meta-data, changelog, ทุกอย่างที่เป็นไปได้ tarballs แหล่งที่มาทั้งหมดและแพทช์ทั้งหมดของแพคเกจทั้งหมดของคุณอยู่ในแหล่งที่มา

ตอนนี้ส่วนตัวแล้วฉันชอบความจริงที่ว่าทุกอย่างเข้าไปในไฟล์ spec และไฟล์ spec นั้นเป็นเอนทิตีที่แยกต่างหากจาก tarball ต้นทาง แต่ฉันไม่กระตือรือร้นอย่างมากที่จะมีแหล่งข้อมูลทั้งหมดในแหล่งที่มา IMHO แหล่งที่มาได้รับความยุ่งเหยิงอย่างรวดเร็วและคุณมักจะติดตามสิ่งที่อยู่ในนั้น อย่างไรก็ตามความคิดเห็นที่แตกต่าง

สำหรับ RPMs มันเป็นสิ่งสำคัญที่จะใช้ที่แน่นอน tarball เดียวกับรุ่นโครงการต้นน้ำถึงการประทับเวลา โดยทั่วไปจะไม่มีข้อยกเว้นสำหรับกฎนี้ แพ็คเกจ Debian ต้องการ tarball เดียวกันกับ upstream ถึงแม้ว่านโยบาย Debian ต้องการให้ tarball บางอันทำการบรรจุใหม่ (ขอบคุณ Umang)

แพ็คเกจ Debian ใช้แนวทางที่แตกต่าง (ให้อภัยข้อผิดพลาดใด ๆ ที่นี่: ฉันมีประสบการณ์น้อยมากกับ deb ของที่ฉันอยู่กับ RPM ของ.) ไฟล์การพัฒนาแพคเกจ Debian มีอยู่ในไดเรกทอรีต่อแพคเกจ

สิ่งที่ฉัน (คิดว่า) ชอบเกี่ยวกับวิธีนี้คือความจริงที่ว่าทุกสิ่งมีอยู่ในไดเรกทอรีเดียว

ในโลก Debian เป็นที่ยอมรับกันอีกเล็กน้อยในการพกพาแพทช์ในแพ็คเกจที่ยังไม่ได้อัปสตรีม ในโลก RPM (อย่างน้อยก็ในกลุ่ม Red Hat Derivatives) เรื่องนี้เกิดขึ้น ดู"FedoraProject: อยู่ใกล้กับโครงการต้นน้ำ"

นอกจากนี้ Debian ยังมีสคริปต์จำนวนมากที่สามารถสร้างส่วนใหญ่โดยอัตโนมัติได้ ยกตัวอย่างเช่นการสร้าง - ง่าย - แพคเกจของโปรแกรมหลาม setuptool'ed, debuildเป็นง่ายๆเป็นสร้างคู่ของไฟล์ข้อมูลเมตาและการทำงาน ที่กล่าวว่าไฟล์สเป็คสำหรับแพ็คเกจดังกล่าวในรูปแบบ RPM นั้นค่อนข้างสั้นและในโลก RPM ก็มีหลายสิ่งที่อัตโนมัติในทุกวันนี้

ผู้คนจำนวนมากเมื่อเทียบกับการติดตั้งซอฟต์แวร์apt-getการrpm -iและดังนั้นจึงพูด DEB ดีกว่า อย่างไรก็ตามสิ่งนี้ไม่เกี่ยวข้องกับรูปแบบไฟล์ DEB การเปรียบเทียบที่แท้จริงคือdpkgVS rpmและaptitude/ apt-*VS /zypperyum

จากมุมมองของผู้ใช้เครื่องมือเหล่านี้มีความแตกต่างไม่มากนัก รูปแบบ RPM และ DEB เป็นเพียงไฟล์เก็บถาวรโดยมีเมตาดาต้าบางส่วนเชื่อมต่ออยู่ พวกเขาทั้งคู่มีความเท่าเทียมกันมีเส้นทางการติดตั้งฮาร์ดโค้ด (yuck!) และแตกต่างกันในรายละเอียดที่ละเอียดอ่อนเท่านั้น ทั้งสองdpkg -iและrpm -iไม่มีวิธีการหาวิธีการติดตั้งการพึ่งพายกเว้นว่าจะเกิดขึ้นกับการระบุในบรรทัดคำสั่ง

ด้านบนของเครื่องมือเหล่านี้มีการจัดการพื้นที่เก็บข้อมูลในรูปแบบของapt-...หรือ/zypper yumเครื่องมือเหล่านี้ดาวน์โหลดที่เก็บติดตามข้อมูลเมตาทั้งหมดและทำการดาวน์โหลดการอ้างอิงโดยอัตโนมัติ การติดตั้งขั้นสุดท้ายของแต่ละแพ็คเกจจะถูกส่งมอบให้กับเครื่องมือระดับต่ำ

เป็นเวลานานที่apt-getยอดเยี่ยมในการประมวลผลข้อมูลเมตาดาต้าจำนวนมหาศาลอย่างรวดเร็วจริง ๆ ในขณะที่yumใช้เวลานานในการทำ RPM ได้รับความเดือดร้อนจากเว็บไซต์เช่น rpmfind ซึ่งคุณจะพบแพ็คเกจที่เข้ากันไม่ได้ 10+ แพคเกจสำหรับการแจกแจงที่แตกต่างกัน Aptซ่อนปัญหานี้อย่างสมบูรณ์สำหรับแพ็คเกจ DEB เนื่องจากแพ็คเกจทั้งหมดได้รับการติดตั้งจากแหล่งเดียวกัน

ในความคิดของฉันzypperได้ปิดช่องว่างไปaptและไม่มีเหตุผลที่จะละอายใจที่จะใช้การกระจายแบบ RPM เป็นเรื่องที่ดีถ้าไม่สะดวกในการใช้บริการ openSUSE build ในมือสำหรับดัชนีแพคเกจที่เข้ากันได้มาก

จากมุมมองของผู้ดูแลระบบฉันพบความแตกต่างเล็ก ๆ น้อย ๆ ส่วนใหญ่ในชุดเครื่องมือ dpkg / rpm มากกว่ารูปแบบแพคเกจ

• dpkg-divertทำให้เป็นไปได้ที่จะมีไฟล์ของคุณเองแทนที่ไฟล์ที่มาจากแพ็คเกจ มันสามารถช่วยชีวิตเมื่อคุณมีโปรแกรมที่ค้นหาไฟล์ใน/usrหรือ/libและจะไม่/usr/localตอบคำถาม มีการนำเสนอแนวคิด แต่เท่าที่ฉันสามารถบอกได้ว่าไม่เป็นลูกบุญธรรมในรอบต่อนาที

• เมื่อฉันจัดการระบบที่ใช้ rpm เป็นครั้งสุดท้าย (ซึ่งเป็นที่ยอมรับเมื่อหลายปีก่อนอาจมีการปรับปรุงสถานการณ์) rpm จะเขียนทับแฟ้มการกำหนดค่าที่แก้ไขแล้วและย้ายการปรับแต่งของฉันไปที่*.rpmsave(IIRC) นี่ทำให้ระบบของฉันไม่สามารถบูตได้อย่างน้อยหนึ่งครั้ง Dpkg ถามฉันว่าจะทำอย่างไรโดยให้การปรับแต่งของฉันเป็นค่าเริ่มต้น

• แพ็คเกจไบนารี rpm สามารถประกาศการขึ้นต่อกันของไฟล์ได้มากกว่าแพ็คเกจซึ่งช่วยให้สามารถควบคุมได้ดีกว่าแพ็คเกจ deb

• คุณไม่สามารถติดตั้งแพ็กเกจเวอร์ชัน N rpm บนระบบที่มีเวอร์ชัน N-1 ของเครื่องมือ rpm นั่นอาจนำไปใช้กับ dpkg ด้วยเช่นกันยกเว้นรูปแบบที่ไม่เปลี่ยนแปลงบ่อยนัก

• ฐานข้อมูล dpkg ประกอบด้วยไฟล์ข้อความ ฐานข้อมูลรอบต่อนาทีเป็นไบนารี ทำให้ฐานข้อมูล dpkg ง่ายต่อการตรวจสอบและซ่อมแซม ในทางกลับกันตราบใดที่ไม่มีสิ่งใดผิดพลาดรอบต่อนาทีจะเร็วขึ้นมาก (การติดตั้ง deb ต้องอ่านไฟล์ขนาดเล็กหลายพันไฟล์)

• แพคเกจ deb ใช้เป็นรูปแบบมาตรฐาน ( ar, tar, gzip) เพื่อให้คุณสามารถตรวจสอบและในบิดหยิก) แพคเกจ deb ได้อย่างง่ายดาย แพ็คเกจ RPM นั้นไม่เป็นมิตร

RPM:

• 'มาตรฐาน' (ไม่ใช่ว่าไม่มีสเป็คเสริม)
• ใช้โดยการกระจายที่แตกต่างกันมากมาย (แต่แพ็คเกจจากที่หนึ่งไม่จำเป็นต้องทำงานในที่อื่น)
• IIRC อนุญาตให้พึ่งพาไฟล์ได้ไม่เพียง แต่บนแพ็คเกจเท่านั้น

DEB:

• ความนิยมที่เพิ่มขึ้น
• อนุญาตการแนะนำและคำแนะนำ (อาจเป็น RPM ที่ใหม่กว่าก็อนุญาตเช่นกัน)

อาจเป็นคำถามที่สำคัญกว่านี้คือตัวจัดการแพ็กเกจ (dpkg vs. yum vs. aptitude เป็นต้น) แทนที่จะเป็นรูปแบบแพ็กเกจ

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

• ปรัชญาของการออกแบบบรรจุภัณฑ์ดั้งเดิมและกลุ่มเป้าหมาย
• ขนาดชุมชนและตามส่วนขยายคุณภาพและความสมบูรณ์ของที่เก็บ

ปรัชญา:

ในโลก Ubuntu / Debian / Mint / ... ผู้ใช้คาดหวังว่าแพ็คเกจที่ติดตั้งจะ "ทำงานได้" เมื่อติดตั้งแล้ว ซึ่งหมายความว่าระหว่างการติดตั้งแพ็คเกจคาดว่าจะดูแลทุกอย่างที่จำเป็นเพื่อให้ใช้งานได้จริงรวมถึง แต่ไม่ จำกัด เพียง:

• การตั้งค่างาน cron ที่จำเป็นหรือเป็นทางเลือก
• การตั้งค่าทางเลือก / ชื่อแทน
• การตั้งค่าสคริปต์เริ่มต้น / ปิดเครื่อง
• รวมถึงไฟล์การกำหนดค่าที่จำเป็นทั้งหมดพร้อมค่าเริ่มต้นที่สมเหตุสมผล
• การรักษาไลบรารีเวอร์ชันเก่าและเพิ่ม symlinked เวอร์ชันที่ถูกต้องให้กับไลบรารี (.so's) เพื่อความเข้ากันได้แบบย้อนหลัง
• รองรับไบนารี่แบบ multi-arch (32 และ 64 บิต) บนเครื่องเดียวกันและอื่น ๆ

ในโลกรอบต่อนาที - เป็นที่ยอมรับกันว่านี่เป็นสถานการณ์เมื่อหลายปีก่อนและมันอาจจะดีขึ้นตั้งแต่นั้นมา - ฉันพบว่าตัวเองต้องทำตามขั้นตอนเพิ่มเติม (เช่น chkconfig เปิดใช้งาน cron) เพื่อให้บรรจุภัณฑ์ใช้งานได้จริง สิ่งนี้อาจโอเคสำหรับผู้ดูแลระบบหรือผู้ที่มีความรู้เกี่ยวกับระบบปฏิบัติการยูนิกซ์ แต่มันก็ทำให้ประสบการณ์ใหม่ ๆ ที่ต้องทนทุกข์ทรมาน โปรดทราบว่าไม่ใช่ว่ารูปแบบแพ็กเกจ RPM นั้นจะป้องกันไม่ให้เกิดขึ้นมันเป็นเพียงว่าแพ็กเกจจำนวนมากไม่ได้"ทำเสร็จสมบูรณ์"จากมุมมองของมือใหม่

ขนาดชุมชนการมีส่วนร่วมและความร่ำรวยของที่เก็บ:

เนื่องจากชุมชน ubuntu / debian / mint / ... มีขนาดใหญ่ขึ้นผู้คนจำนวนมากมีส่วนร่วมในซอฟต์แวร์การบรรจุและทดสอบ ฉันพบความร่ำรวยและคุณภาพของแหล่งเก็บข้อมูลที่เหนือกว่า ในอูบุนตูฉันแทบจะไม่ต้องดาวน์โหลดแหล่งที่มาและสร้างมันเลย เมื่อฉันเปลี่ยนจาก Red Hat เป็น Ubuntu ที่บ้าน repo RHEL ทั่วไปมี ~ 3000 แพ็คเกจในขณะที่ในเวลาเดียวกัน ubuntu + universe + multiverse ทั้งหมดสามารถใช้ได้โดยตรงจากกระจก Canonical ใด ๆ มี ~ 30,000 แพ็คเกจ (ประมาณ 10x) แพ็กเกจส่วนใหญ่ที่ฉันค้นหาในรูปแบบ RPM ไม่สามารถเข้าถึงได้อย่างง่ายดายผ่านการค้นหาอย่างง่ายและคลิกในเครื่องมือจัดการแพคเกจ พวกเขาจำเป็นต้องเปลี่ยนไปใช้แหล่งเก็บข้อมูลอื่นค้นหาเว็บไซต์บริการ rpmfind เป็นต้นโดยส่วนใหญ่แล้วแทนที่จะแก้ไขปัญหา ทำลายการติดตั้งของฉันโดยไม่สามารถ จำกัด การพึ่งพาที่สามารถหรือไม่สามารถอัปเกรดได้อย่างถูกต้อง ฉันพบปรากฏการณ์ "การพึ่งพานรก" ตามที่อธิบายไว้ข้างต้นโดย Shawn J. Goff

ในทางตรงกันข้ามใน Ubuntu / Debian ฉันพบว่าฉันแทบไม่จำเป็นต้องสร้างจากแหล่งที่มา ยังเป็นเพราะ:

• รอบการเปิดตัว Ubuntu รวดเร็ว (6 เดือน)
• การมีอยู่ของPPAs ที่เข้ากันได้อย่างสมบูรณ์ซึ่งทำงานนอกกรอบ
• แหล่งเก็บข้อมูลเดียว (โฮสต์ทั้งหมดโดย Canonical) ไม่จำเป็นต้องค้นหา repos สำรอง / เสริม
• ประสบการณ์การใช้งานที่ราบรื่นจากคลิกเพื่อเรียกใช้

ฉันไม่เคยต้องประนีประนอมกับแพ็คเกจเก่า ๆ ที่ฉันห่วงใยแม้ว่าพวกเขาจะไม่ได้รับการดูแลจากนักพัฒนาอย่างเป็นทางการ (Canonical) ก็ตาม ฉันไม่เคยออกจากผู้จัดการแพ็คเกจ GUI ที่เป็นมิตรที่ฉันโปรดปรานเพื่อทำการค้นหาที่สะดวกโดยใช้คำหลักเพื่อค้นหาและติดตั้งแพ็คเกจที่ฉันต้องการ นอกจากนี้สองสามครั้งที่ฉันติดตั้งแพคเกจ debian (ไม่ใช่ Canonical) บน Ubuntu และพวกเขาทำงานได้ดีแม้ว่าความเข้ากันได้นี้จะไม่รับประกันอย่างเป็นทางการ

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

ฉันคิดว่าอคติไม่ได้มาจากรูปแบบแพ็คเกจ แต่จากความไม่สอดคล้องที่เคยมีอยู่ในที่เก็บของ RedHat

ย้อนกลับไปเมื่อ RedHat เป็นการแจกจ่าย (ก่อนวัน RHEL, Fedora และ Fedora Core) บางครั้งผู้คนจะพบว่าตัวเองอยู่ใน "RPM Hell" หรือ "Hell dependency" สิ่งนี้เกิดขึ้นเมื่อที่เก็บจะจบลงด้วยแพ็กเกจที่มีการอ้างอิง (หลายชั้นลึกมัก) ซึ่งเป็นเอกสิทธิ์เฉพาะบุคคลร่วมกัน หรือมันจะเกิดขึ้นเมื่อสองแพ็คเกจที่ต่างกันมีการพึ่งพาซึ่งกันและกันแบบเอกสิทธิ์เฉพาะบุคคลสองรายการ นี่เป็นปัญหากับสถานะของที่เก็บไม่ใช่กับรูปแบบแพ็คเกจ "RPM Hell" ทิ้งความไม่พอใจให้กับระบบ RPM ในกลุ่มประชากรของผู้ใช้งาน Linux ที่ได้รับผลกระทบจากปัญหา

นอกจากนี้ยังมี "ปรัชญา" ที่แตกต่างกันซึ่งในแพ็คเกจเดเบียนคุณสามารถถามคำถามและสิ่งนี้บล็อกกระบวนการติดตั้ง ข้อดีของมันก็คือแพคเกจบางตัวจะบล็อกการอัพเกรดของคุณจนกว่าคุณจะตอบกลับ ข้อดีของมันก็คือความแตกต่างทางปรัชญาในระบบที่ใช้เดเบียนเมื่อมีการติดตั้งแพคเกจมันก็จะถูกกำหนดค่า (ไม่จำเป็นเสมอไป) และทำงานอยู่ ไม่ได้อยู่ในระบบที่ใช้ Redhat ซึ่งคุณต้องสร้าง / คัดลอกจาก / usr / share / doc / * ไฟล์กำหนดค่าเริ่มต้น / แม่แบบ

สิ่งหนึ่งที่ฉันชอบเกี่ยวกับ RPMs คือการเพิ่ม delta RPMs (ล่าสุด) สิ่งนี้ช่วยให้การอัพเดตง่ายขึ้นลดแบนด์วิดท์ที่จำเป็น

DEBs เป็นไฟล์ ar มาตรฐาน (ด้วยคลังเก็บมาตรฐานภายในเพิ่มเติม) RPMs เป็นไฟล์ไบนารี "กรรมสิทธิ์" ส่วนตัวผมคิดว่าอดีตนั้นสะดวกกว่า

มีเพียงสองอย่างที่ฉันสามารถคิดได้จากส่วนบนของหัว ทั้งสองมีความคล้ายคลึงกันมาก ทั้งสองมีเครื่องมือที่ยอดเยี่ยมสำหรับบรรจุภัณฑ์ ฉันไม่คิดว่ามีข้อดีมากมายสำหรับสิ่งใดสิ่งหนึ่งเหนือสิ่งอื่นหรือในทางกลับกัน

openSUSE Build Service (OBS) และ zypper เป็นสองเหตุผลที่ฉันชอบ RPM มากกว่า deb จากผู้ทำแพ็กเกจและมุมมองผู้ใช้ Zypper เดินทางมาไกลและค่อนข้างเร็ว OBS แม้ว่าจะสามารถจัดการกับ debs ได้ดีจริง ๆ เมื่อมันมาถึง rpms บรรจุภัณฑ์สำหรับแพลตฟอร์มต่าง ๆ เช่น openSUSE, SLE, RHEL, centos, fedora, mandriva ฯลฯ

แพ็คเกจ Debian อาจมีขนาดที่ติดตั้งไว้แต่ฉันไม่เชื่อว่า RPMs จะมีขนาดเท่ากัน สามารถคำนวณได้ตามไฟล์ที่รวมอยู่ในแพ็คเกจ แต่ไม่สามารถเชื่อถือได้เนื่องจากการกระทำที่สามารถทำได้ในสคริปต์การติดตั้งก่อน / หลัง

นี่คือการอ้างอิงที่ดีมากสำหรับการเปรียบเทียบคุณสมบัติเฉพาะบางอย่างที่มีอยู่ในแต่ละรูปแบบบรรจุภัณฑ์เฉพาะ: http://debian-br.sourceforge.net/txt/alien.htm (ตามเว็บเซิร์ฟเวอร์เอกสารดังกล่าวค่อนข้างเก่า : แก้ไขครั้งสุดท้าย: Sun, 15 Oct 2000ดังนั้นนี่อาจไม่ใช่การอ้างอิงที่ดีที่สุด)

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

ไม่มีคำตอบอื่นใดที่สัมผัสว่าความแตกต่างพื้นฐานสามประการต่อไปนี้มีผลกระทบที่แท้จริงอย่างไร:

1. debไฟล์โดยทั่วไปเป็นเพียงarคลังเก็บที่มี tarballs บีบอัดสอง
2. debแพ็คเกจและdpkgระบบจัดเก็บสคริปต์ผู้ดูแลของคุณเป็นไฟล์แยก
3. dpkgและrpmเรียกใช้สคริปต์ผู้ดูแลในลำดับที่แตกต่างกันในระหว่างการอัพเกรด

ร่วมกันแตกต่างเหล่านี้ได้ทำให้มันง่ายมากสำหรับผมที่จะแก้ไขปัญหาที่เกิดจากแพคเกจที่ไม่ดีและจะทำให้แพคเกจในลักษณะที่ฉันต้องการให้พวกเขาในการdebตามระบบกว่าrpmตามระบบทั้งในฐานะผู้ดูแลระบบและเป็นแพกเกจ .

เพราะ # 1 ถ้าฉันต้องการที่จะเปลี่ยนdebไฟล์ฉันสามารถนิดป๊อปมันเปิดทำการเปลี่ยนแปลงใด ๆ ที่ฉันต้องการและ repackage มันโดยใช้เครื่องมือมาตรฐานที่มีอยู่ในระบบส่วนใหญ่

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

เพราะ # 2 หากมีปัญหาในการ "ลบ" สคริปต์การติดตั้งโดยแพคเกจที่ติดตั้งอยู่แล้วผมสามารถนิดแก้ไขได้โดยใช้เครื่องมือมาตรฐานที่มีอยู่ในระบบใด ๆ

เนื่องจาก # 3 ฉันสามารถแก้ไขได้เพียงแค่ปล่อยแพ็คเกจใหม่ของฉันเนื่องจากในระหว่างการอัปเกรดให้dpkgเรียกใช้สคริปต์ "ติดตั้งล่วงหน้า" ของแพ็คเกจเวอร์ชันใหม่ก่อนสคริปต์ "post-remove" ของ รุ่นเก่า

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

และเนื่องจากการปรับเปลี่ยนแพคเกจนั้นง่ายมาก - ซอฟท์แวร์เฉพาะแพคเกจและความรู้ที่แท้จริงนั้นเล็กมาก - ผู้คนสามารถเข้าถึงได้มากขึ้นและใช้เวลาและความพยายามน้อยลงด้วยdebไฟล์