Dependency hellเป็นคำที่ใช้กันทั่วไปสำหรับความรู้สึกหงุดหงิดของผู้ใช้ซอฟต์แวร์บางรายที่ติดตั้งแพ็กเกจซอฟต์แวร์ที่มีการพึ่งพาเวอร์ชันเฉพาะของแพ็กเกจซอฟต์แวร์อื่น^{[ 1 ]}

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

ปัญหาความซับซ้อนของการพึ่งพาไลบรารีมีหลายรูปแบบ:

แอปพลิเคชันขึ้นอยู่กับไลบรารี จำนวนมาก ซึ่งต้องใช้เวลาดาวน์โหลดนาน ใช้พื้นที่ดิสก์จำนวนมาก และพกพาได้ยาก (ไลบรารีทั้งหมดได้รับการพอร์ตแล้ว ทำให้แอปพลิเคชันสามารถพอร์ตได้ง่าย) นอกจากนี้ยังอาจยากที่จะค้นหาการพึ่งพาทั้งหมด ซึ่งสามารถแก้ไขได้โดยการมีที่เก็บ (ดูด้านล่าง) นี่เป็นสิ่งที่หลีกเลี่ยงไม่ได้บางส่วน แอปพลิเคชันที่สร้างขึ้นบนแพลตฟอร์มการประมวลผล ที่กำหนด (เช่นJava ) จำเป็นต้องติดตั้งแพลตฟอร์มนั้น แต่แอปพลิเคชันอื่นๆ ไม่จำเป็นต้องใช้แพลตฟอร์มนั้น นี่เป็นปัญหาโดยเฉพาะอย่างยิ่งหากแอปพลิเคชันใช้ส่วนเล็กๆ ของไลบรารีขนาดใหญ่ (ซึ่งสามารถแก้ไขได้โดยการปรับโครงสร้างโค้ด ) หรือแอปพลิเคชันง่ายๆ พึ่งพาไลบรารีจำนวนมาก^{[ 2 ]}

หากแอปขึ้นอยู่กับlibaซึ่งขึ้นอยู่กับlibb ... ซึ่งขึ้นอยู่กับlibzนี่แตกต่างจาก "การพึ่งพาจำนวนมาก" หากต้องแก้ไขการพึ่งพาด้วยตนเอง เช่น เมื่อพยายามติดตั้งแอปผู้ใช้จะได้รับแจ้งให้ติดตั้งlibaก่อน และเมื่อพยายามติดตั้งlibaผู้ใช้จะได้รับแจ้งให้ติดตั้งlibbและอื่นๆ ต่อไป อย่างไรก็ตาม บางครั้งในห่วงโซ่การพึ่งพาที่ยาวนี้ อาจเกิดข้อขัดแย้งขึ้นเมื่อต้องการแพ็กเกจเวอร์ชันที่แตกต่างกันสองเวอร์ชัน^{[ 3 ]} (ดูการพึ่งพาที่ขัดแย้งกันด้านล่าง) ห่วงโซ่การพึ่งพาที่ยาวเหล่านี้สามารถแก้ไขได้โดยการมีตัวจัดการแพ็กเกจที่แก้ไขการพึ่งพาทั้งหมดโดยอัตโนมัติ นอกเหนือจากความยุ่งยาก (ในการแก้ไขการพึ่งพาทั้งหมดด้วยตนเอง) การแก้ไขด้วยตนเองอาจปกปิดวงจรการพึ่งพาหรือข้อขัดแย้งได้

การแก้ปัญหาการพึ่งพาของซอฟต์แวร์หนึ่งอาจทำให้ซอฟต์แวร์อื่นใช้งานร่วมกันไม่ได้ ในลักษณะเดียวกับการเล่นเกมตีตัวตุ่น เช่น ถ้าapp1ขึ้นอยู่กับlibfoo 1.2 และapp2ขึ้นอยู่กับlibfoo 2.0 และไม่สามารถติดตั้งlibfoo เวอร์ชันต่างๆ พร้อมกันได้ ดังนั้น app1และapp2ก็จะไม่สามารถใช้งานพร้อมกันได้ (หรือติดตั้งพร้อมกันไม่ได้ หากตัวติดตั้งตรวจสอบการพึ่งพา) วิธีแก้ปัญหาที่เป็นไปได้คือการอนุญาตให้ติดตั้งการพึ่งพาที่แตกต่างกันพร้อมกัน หรืออีกทางเลือกหนึ่งคือ ต้องถอนการติดตั้งการพึ่งพาที่มีอยู่พร้อมกับซอฟต์แวร์ทั้งหมดที่ขึ้นอยู่กับมัน เพื่อติดตั้งการพึ่งพาใหม่ ปัญหาในระบบ Linux เมื่อติดตั้งแพ็กเกจจากผู้จัดจำหน่ายที่แตกต่างกันคือ ห่วงโซ่การพึ่งพาที่ยาวอาจนำไปสู่เวอร์ชันที่ขัดแย้งกันของไลบรารีมาตรฐาน C (เช่นไลบรารี C ของ GNU ) ซึ่งมีแพ็กเกจหลายพันรายการขึ้นอยู่กับ หากเกิดเหตุการณ์นี้ขึ้น ผู้ใช้จะได้รับแจ้งให้ถอนการติดตั้งแพ็กเกจเหล่านั้นทั้งหมด

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

เป็นไปได้^{[ 4 ]}ที่ปัญหาการพึ่งพา (dependency hell) จะเกิดขึ้นจากการติดตั้งแพ็กเกจที่เตรียมไว้ผ่านตัวจัดการแพ็กเกจ (เช่นAPT ) แต่ไม่น่าจะเกิดขึ้นเนื่องจากตัวจัดการแพ็กเกจหลักๆ มีความสมบูรณ์และคลังเก็บอย่างเป็นทางการได้รับการดูแลเป็นอย่างดี กรณีนี้เกิดขึ้นกับDebian เวอร์ชันปัจจุบัน และระบบปฏิบัติการที่พัฒนาต่อยอดจาก Debian เช่นUbuntuอย่างไรก็ตาม ปัญหาการพึ่งพา (dependency hell) อาจเกิดขึ้นจากการติดตั้งแพ็กเกจโดยตรงผ่านตัวติดตั้งแพ็กเกจ (เช่นRPM Package Manager (RPM) หรือdpkg )

เมื่อไลบรารีAขึ้นอยู่กับไลบรารีBและCทั้งBและCก็ขึ้นอยู่กับไลบรารีDเช่นกัน แต่Bต้องการเวอร์ชันD.1และCต้องการเวอร์ชันD.2การสร้างจะล้มเหลวเนื่องจาก จะมีไลบรารี D เพียงเวอร์ชันเดียวเท่านั้น ในไฟล์ปฏิบัติการสุดท้าย

ตัวจัดการแพ็กเกจเช่นyum ^{[ 5 ]}มีแนวโน้มที่จะเกิดความขัดแย้งระหว่างแพ็กเกจในที่เก็บ ทำให้เกิดปัญหาการพึ่งพาในระบบปฏิบัติการ Linux เช่นCentOSและRed Hat Enterprise Linux

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

วิธีแก้ปัญหาที่พบได้บ่อยมากคือการใช้ระบบการกำหนดหมายเลขมาตรฐาน โดยซอฟต์แวร์จะใช้หมายเลขเฉพาะสำหรับแต่ละเวอร์ชัน (หรือที่เรียกว่าเวอร์ชันหลัก ) และหมายเลขย่อยสำหรับแต่ละการแก้ไข (หรือที่เรียกว่าเวอร์ชันย่อย ) เช่น10.1หรือ5.7เวอร์ชันหลักจะเปลี่ยนแปลงก็ต่อเมื่อโปรแกรมที่ใช้เวอร์ชันนั้นไม่สามารถใช้งานร่วมกันได้อีกต่อไป เวอร์ชันย่อยอาจเปลี่ยนแปลงได้แม้แต่การแก้ไขเล็กน้อยที่ไม่ทำให้ซอฟต์แวร์อื่นใช้งานไม่ได้ ในกรณีเช่นนี้ แพ็กเกจซอฟต์แวร์สามารถร้องขอส่วนประกอบที่มีเวอร์ชันหลักเฉพาะ และ เวอร์ชันย่อย ใดๆ (มากกว่าหรือเท่ากับเวอร์ชันย่อยเฉพาะ) ได้ ดังนั้น แพ็กเกจเหล่านั้นจะยังคงทำงานได้ และการพึ่งพาจะได้รับการแก้ไขอย่างสำเร็จ แม้ว่าเวอร์ชันย่อยจะเปลี่ยนแปลงก็ตาม การกำหนดเวอร์ชันเชิงความหมาย (หรือที่เรียกว่า "SemVer" ^{[ 6 ]} ) เป็นตัวอย่างหนึ่งของความพยายามในการสร้างข้อกำหนดทางเทคนิคที่ใช้หมายเลขที่จัดรูปแบบเฉพาะเพื่อสร้างแผนการกำหนดเวอร์ชันซอฟต์แวร์

Windows File Protectionซึ่งเปิดตัวในWindows 2000ป้องกันไม่ให้แอปพลิเคชันเขียนทับไลบรารีการเชื่อมโยงแบบไดนามิก (DLL) ของระบบ นักพัฒนาได้รับการสนับสนุนให้ใช้DLL ส่วนตัวซึ่งเป็นสำเนาของ DLL ของระบบที่จัดเก็บไว้ในโฟลเดอร์ของโปรแกรม วิธีนี้ต้องใช้การพึ่งพาแบบกำหนดเองในการบรรจุโปรแกรม จึงป้องกันปัญหาการพึ่งพาที่ซับซ้อนได้^{[ 7 ]}

PC-BSD จนถึงเวอร์ชัน 8.2 ซึ่งเป็นระบบปฏิบัติการรุ่นก่อนหน้าของTrueOS ( ระบบปฏิบัติการที่ใช้FreeBSD เป็นพื้นฐาน ) จะจัดเก็บแพ็กเกจและส่วนประกอบต่างๆ ไว้ในไดเร็กทอรีที่แยกต่างหากใน/Programs ซึ่งจะช่วยหลีกเลี่ยงความเสียหายหากมีการอัปเกรดหรือเปลี่ยนแปลงไลบรารีของระบบ โดยใช้ ตัวติดตั้งแบบกดปุ่ม (PBI) ของตัวเองสำหรับการจัดการแพ็กเกจ^{[ 8 ]}

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

โซลูชันนี้ใช้ใน ระบบปฏิบัติการ Microsoft Windowsตั้งแต่ Windows Vista ซึ่งGlobal Assembly Cacheเป็นการใช้งานรีจิสทรีส่วนกลางดังกล่าวพร้อมบริการที่เกี่ยวข้องและรวมเข้ากับระบบการติดตั้ง/ตัวจัดการแพ็กเกจGentoo Linuxแก้ปัญหานี้ด้วยแนวคิดที่เรียกว่า slotting ซึ่งอนุญาตให้ติดตั้งไลบรารีที่ใช้ร่วมกันได้หลายเวอร์ชัน^{[ 9 ]}

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

ระบบปฏิบัติการ Linuxในปัจจุบันหลายระบบได้นำ ระบบการจัดการแพ็กเกจแบบ อิงตามที่เก็บมาใช้เพื่อพยายามแก้ปัญหาการพึ่งพา ระบบเหล่านี้เป็นเลเยอร์บนตัวจัดการแพ็กเกจ RPM (RPM), dpkg หรือระบบแพ็กเกจอื่นๆ ที่ออกแบบมาเพื่อแก้ไขการพึ่งพาโดยอัตโนมัติโดยการค้นหาใน ที่เก็บซอฟต์แวร์ที่กำหนดไว้ล่วงหน้าอย่างน้อยหนึ่งแห่งตัวอย่างของระบบเหล่านี้ ได้แก่ Advanced Packaging Tool ( APT ), Yum , Urpmi , ZYpp , Portage , Pacmanและอื่นๆ โดยทั่วไป ที่เก็บซอฟต์แวร์จะเป็นไซต์ FTP หรือเว็บไซต์ไดเร็กทอรีบนคอมพิวเตอร์เครื่องโลคัลหรือที่แชร์ผ่านเครือข่ายหรือที่พบได้น้อยกว่ามากคือไดเร็กทอรีบนสื่อแบบถอดได้ เช่น ซีดีหรือดีวีดี ซึ่งจะช่วยขจัดปัญหาการพึ่งพาสำหรับซอฟต์แวร์ที่บรรจุอยู่ในที่เก็บเหล่านั้น ซึ่งโดยทั่วไปแล้วจะได้รับการดูแลโดยผู้ให้บริการระบบปฏิบัติการ Linux และมีการทำสำเนาไว้ทั่วโลก แม้ว่าที่เก็บเหล่านี้มักจะมีขนาดใหญ่ แต่ก็เป็นไปไม่ได้ที่จะมีซอฟต์แวร์ทุกชิ้นอยู่ในนั้น ดังนั้นปัญหาการพึ่งพาจึงยังคงเกิดขึ้นได้ ในทุกกรณี ผู้ดูแลที่เก็บยังคงต้องเผชิญกับปัญหาการพึ่งพาอยู่ดี^{[ 4 ]}

เนื่องจากซอฟต์แวร์แต่ละชิ้นมีส่วนประกอบที่ต้องพึ่งพาแตกต่างกัน จึงอาจทำให้เกิด วงจร การพึ่งพาที่ซับซ้อนหรือโครงสร้างข้อกำหนดที่ขยายตัวขึ้นเรื่อยๆเพราะแต่ละแพ็กเกจใหม่จะต้องการการติดตั้งแพ็กเกจอื่นๆ อีกหลายตัว ระบบอย่างเช่น Advanced Packaging Tool ( APT ) ของ Debian สามารถแก้ไขปัญหานี้ได้โดยการนำเสนอทางเลือกต่างๆ ให้ผู้ใช้ และอนุญาตให้ผู้ใช้ยอมรับหรือปฏิเสธทางเลือกเหล่านั้นได้ตามต้องการ

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

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

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

แอปพลิเคชัน (หรือเวอร์ชันของแอปพลิเคชันทั่วไปที่มีอยู่) ที่มีโครงสร้างแบบครบวงในตัวเองและไม่จำเป็นต้องติดตั้งอะไรไว้ล่วงหน้า มันถูกเขียนโค้ดให้มีส่วนประกอบที่จำเป็นทั้งหมดรวมอยู่ด้วย หรือได้รับการออกแบบให้เก็บไฟล์ที่จำเป็นทั้งหมดไว้ในไดเร็กทอรีของตัวเอง และจะไม่สร้างปัญหาการพึ่งพา แอปพลิเคชันเหล่านี้มักจะสามารถทำงานได้อย่างอิสระจากระบบที่เชื่อมต่ออยู่ แอปพลิเคชันในRISC OSและROX Desktopสำหรับ Linux ใช้ไดเร็กทอรีแอปพลิเคชัน ซึ่งทำงานในลักษณะเดียวกัน: โปรแกรมและการพึ่งพาของโปรแกรมจะอยู่ในไดเร็กทอรี (โฟลเดอร์) ของตัวเอง^{[ 10 ]}

วิธีการแจกจ่ายแบบนี้ยังพิสูจน์แล้วว่ามีประโยชน์เมื่อทำการพอร์ตแอปพลิเคชันที่ออกแบบมาสำหรับแพลตฟอร์มแบบ Unix ไปยัง Windows ข้อเสียที่เห็นได้ชัดที่สุดคือการติดตั้ง ไลบรารีที่ใช้ร่วมกัน เดียวกันหลายครั้ง ตัวอย่างเช่น โปรแกรมติดตั้ง Windows สำหรับgedit , GIMPและHexChatต่างก็มีสำเนาของ ชุดเครื่องมือ GTK ที่เหมือนกัน ซึ่งโปรแกรมเหล่านี้ใช้ในการแสดงผลวิดเจ็ต ในทางกลับกัน หากแต่ละแอปพลิเคชันต้องการ GTK เวอร์ชันที่แตกต่างกัน นี่คือพฤติกรรมที่ถูกต้องและช่วยหลีกเลี่ยงปัญหาการพึ่งพาที่ซับซ้อนได้สำเร็จ

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

• ปัญหา DLL hell – รูปแบบหนึ่งของปัญหาการพึ่งพาไฟล์ที่เกิดขึ้นบนระบบปฏิบัติการ Microsoft Windows 16 บิต
• ความขัดแย้งของส่วนขยาย – รูปแบบหนึ่งของปัญหาการพึ่งพาที่เกิดขึ้นในระบบปฏิบัติการ Mac OS รุ่นคลาสสิก
• ปัญหา JAR hell – รูปแบบหนึ่งของปัญหาการพึ่งพาที่เกิดขึ้นในJava Runtime Environmentก่อนที่เครื่องมือสร้างโปรแกรมอย่างApache Mavenจะแก้ไขปัญหานี้ได้ในปี 2004
• RPM hell – รูปแบบหนึ่งของ dependency hell ที่เกิดขึ้นใน ระบบปฏิบัติการ LinuxของRed Hatและระบบปฏิบัติการอื่นๆ ที่ใช้RPMเป็นตัวจัดการแพ็กเกจ^{[ 11 ]}

• Catch-22 – สถานการณ์ที่การแก้ปัญหาขึ้นอยู่กับสถานการณ์ที่ขัดแย้งกัน ซึ่งตั้งชื่อตามแนวคิดที่อธิบายไว้ในนวนิยายปี 1961
• การจัดการการกำหนดค่า – เทคนิคและเครื่องมือสำหรับการจัดการเวอร์ชันซอฟต์แวร์
• การเชื่อมโยง – รูปแบบของการพึ่งพาซึ่งกันและกันระหว่างส่วนประกอบซอฟต์แวร์
• การกำจัดโค้ดที่ไม่ได้ใช้งานแบบไดนามิก
• ตัวจัดการแพ็กเกจ
• พีบีไอ
• อุปกรณ์ซอฟต์แวร์
• ไลบรารีแบบคงที่
• การโจมตีห่วงโซ่อุปทาน
• Nix (โปรแกรมจัดการแพ็กเกจ)
• เหตุการณ์ left-pad ของ npm