Linux ติดตั้งไม่ได้เพราะ dependency error: สาเหตุและวิธีแก้ไข

ใน Linux เวลาติดตั้งซอฟต์แวร์ มักจะเจอข้อความอย่าง “ไม่สามารถแก้ dependency ได้”, “ไม่พบแพ็กเกจที่ต้องใช้”, หรือ “มีแพ็กเกจที่ขัดแย้งกัน” ข้อความเหล่านี้ไม่ได้หมายความแค่ว่าแอปหนึ่งตัวติดตั้งไม่ได้เท่านั้น แต่บ่อยครั้งเป็นสัญญาณว่าสถานะของแพ็กเกจทั้งระบบเริ่มไม่สอดคล้องกันแล้ว ตัวจัดการแพ็กเกจอย่าง apt, dnf และ pacman ทำงานบนสมมติฐานว่า library, runtime และแพ็กเกจประกอบทั้งหมดอยู่ในชุดเวอร์ชันที่เข้ากันได้ หากโซ่นี้ขาด การติดตั้งจะถูกหยุดทันที

สิ่งสำคัญคืออย่ามอง dependency error ว่าเป็นปัญหาเล็ก ๆ แบบ “ขาดแค่แพ็กเกจเดียว” เพราะเบื้องหลังอาจเกิดจาก cache เสีย, repository เก่า, การผสม source จากหลายที่, การอัปเดตที่ถูกขัดจังหวะ, partial upgrade, แพ็กเกจที่ถูก hold, library ที่ติดตั้งด้วยมือ หรือแม้แต่ architecture ไม่ตรงกัน ดังนั้นจึงไม่ควรเริ่มจากการลบไฟล์แบบสุ่มหรือไปหา .deb / .rpm จากเว็บที่ไม่น่าเชื่อถือมาติดตั้ง แต่ควรทำความเข้าใจก่อนว่าจริง ๆ แล้ว dependency ตัวไหนที่ไม่ผ่าน และเพราะอะไร

dependency error คืออะไร

แพ็กเกจใน Linux ส่วนใหญ่ไม่ได้ทำงานอย่างโดดเดี่ยว โปรแกรมหนึ่งอาจต้องการ library เฉพาะ, runtime เวอร์ชันหนึ่ง, เครื่องมือเสริม หรือองค์ประกอบอื่นในระบบ ถ้าสิ่งใดสิ่งหนึ่งขาดหายไป หรือมีเวอร์ชันไม่ตรงตามที่ต้องการ ตัวจัดการแพ็กเกจก็จะหยุดการติดตั้งเพื่อป้องกันไม่ให้ระบบเสียหายมากขึ้น

ดังนั้น dependency error ไม่ได้แปลว่า “มีอะไรหายไป” เท่านั้น บางครั้งมันหมายถึงมีสองเงื่อนไขที่เกิดพร้อมกันไม่ได้, มีแพ็กเกจที่ชนกัน, หรือเวอร์ชันที่มีอยู่ไม่สามารถประกอบกันเป็นสถานะที่สอดคล้องกันได้

อาการที่พบบ่อย

• มีข้อความ Depends:, requires หรือ unresolved dependency
• ระบบแจ้งว่ามีแพ็กเกจเสียหรือ dependency ไม่สามารถแก้ได้
• ต้องการติดตั้งแพ็กเกจหนึ่ง แต่ระบบกลับขอให้ลบอีกแพ็กเกจหนึ่ง
• ต้องใช้ library บางตัว แต่ไม่มีเวอร์ชันที่ตรงกัน
• หลังอัปเดตแล้วการติดตั้งเริ่มล้มเหลวตลอด
• ปัญหาเริ่มหลังจากเพิ่ม repository จากภายนอก
• หลัง partial upgrade ระบบเกิดความไม่สอดคล้องกัน

สิ่งที่ควรตรวจสอบก่อน

บางครั้งสิ่งที่ดูเหมือน dependency error จริง ๆ แล้วเกิดจาก network, DNS หรือ mirror มีปัญหา ดังนั้นควรตรวจสอบก่อนว่าสามารถเข้าถึงแหล่งแพ็กเกจได้ตามปกติหรือไม่

ping -c 4 8.8.8.8
ping -c 4 google.com
ip addr
ip route

หลังจากนั้นให้ลองรีเฟรชรายการแพ็กเกจดูว่าเสร็จสมบูรณ์หรือไม่

sudo apt update
sudo dnf makecache
sudo pacman -Sy

ถ้าขั้นตอนนี้มี 404, แก้ชื่อโดเมนไม่ได้, signature error หรือ timeout ปัญหาหลักอาจไม่ได้อยู่ที่ dependency โดยตรง แต่อยู่ที่การเข้าถึง repository

สาเหตุหลักของ dependency error

1. การผสม repository หลายแหล่ง

นี่เป็นสาเหตุที่พบบ่อยมาก repository ทางการ, PPA เก่า, source ของคนละ release, testing repository และ source ของ third-party อาจให้ชื่อแพ็กเกจเหมือนกัน แต่มีเวอร์ชันและเงื่อนไข dependency ต่างกัน ผลคือแพ็กเกจหนึ่งต้องการ library ใหม่ ขณะที่อีกแพ็กเกจหนึ่งต้องการ library เก่า และระบบไม่สามารถทำให้ทั้งสองอย่างถูกต้องพร้อมกันได้

2. การอัปเดตถูกขัดจังหวะ

ถ้าการอัปเดตถูกหยุดกลางทางเพราะไฟดับ, ปิด terminal, SSH หลุด หรือ GUI ค้าง บางแพ็กเกจอาจถูกอัปเดตแล้ว แต่บางแพ็กเกจยังคงเป็นเวอร์ชันเก่า สถานะแบบครึ่งเก่าครึ่งใหม่นี้ทำให้ dependency พังได้ง่ายมาก

3. partial upgrade

ปัญหานี้เป็นที่รู้จักอย่างมากใน Arch Linux เพราะ partial upgrade ถือว่าไม่ควรทำอย่างยิ่ง แต่ใน Debian / Ubuntu หรือ Fedora เอง การบังคับอัปเดตเฉพาะบางแพ็กเกจสำคัญโดยไม่อัปเดตทั้งระบบ ก็ทำให้เกิดปัญหาแบบเดียวกันได้

4. แพ็กเกจที่ถูก hold หรือ pin ไว้

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

5. การติดตั้งด้วยมือนอก package manager

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

6. แพ็กเกจที่ขัดแย้งกัน

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

7. architecture ไม่ตรงกัน

แพ็กเกจอาจมีอยู่จริง แต่ไม่ใช่สำหรับ architecture ที่ถูกต้อง เช่น การผสม 32-bit กับ 64-bit โดยไม่มีการตั้งค่าให้ถูกต้อง หรือการพยายามติดตั้งแพ็กเกจของ architecture อื่น ก็อาจแสดงผลออกมาเป็น dependency error ได้เช่นกัน

8. cache หรือ metadata ไม่สอดคล้องกัน

รายการแพ็กเกจเก่า, cache เสีย, หรือ metadata ของ mirror ที่ไม่ตรงกัน อาจทำให้ package manager “มองไม่เห็น” dependency ที่จริง ๆ แล้วมีอยู่ใน repository

สิ่งที่ควรตรวจในระบบ apt

ใน Debian / Ubuntu ควรตรวจไม่ใช่แค่ apt แต่รวมถึงสถานะของ dpkg ด้วย

ซ่อมสถานะที่ค้างไม่สมบูรณ์

sudo dpkg --configure -a
sudo apt --fix-broken install

หลังจากการอัปเดตที่ถูกขัดจังหวะ คำสั่งสองตัวนี้มักเป็นจุดเริ่มต้นที่ถูกต้องที่สุด

ตรวจสอบแพ็กเกจที่ถูก hold

apt-mark showhold

แพ็กเกจที่ถูก hold อาจขวาง dependency chain ทั้งหมด

ตรวจดูเวอร์ชันและแหล่งที่มา

apt-cache policy ชื่อแพ็กเกจ

จะช่วยให้เห็นว่าเวอร์ชันที่มีอยู่มาจาก repository ไหนบ้าง

สิ่งที่ควรตรวจในระบบ dnf

ใน Fedora / RHEL ควรให้ความสำคัญกับความสมบูรณ์ของระบบและประวัติ transaction

ตรวจสถานะปัจจุบัน

sudo dnf check

ช่วยค้นหา unsatisfied dependencies ทั้งระบบ

ซิงก์ให้ตรงกับสถานะของ distribution

sudo dnf distro-sync

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

ดู requirements ที่ยังไม่ผ่าน

sudo dnf repoquery --unsatisfied

จะช่วยให้เห็นชัดขึ้นว่า dependency ตัวไหนที่ยังไม่ถูกตอบสนอง

สิ่งที่ควรตรวจในระบบ pacman

ใน Arch Linux สิ่งสำคัญที่สุดคือทำให้ทั้งระบบกลับมาสอดคล้องกัน และหลีกเลี่ยง partial upgrade

อัปเดตทั้งระบบ

sudo pacman -Syu

หากมี dependency error อยู่แล้ว การพยายามแก้ด้วยการอัปเดตทีละแพ็กเกจมักทำให้แย่ลง

รีเฟรชฐานข้อมูล sync

sudo pacman -Syy

มีประโยชน์เมื่อข้อมูลในเครื่องไม่ตรงกับ mirror แล้ว

Log สำคัญมาก

dependency error มักเข้าใจไม่ได้จากแค่บรรทัดสุดท้าย ต้องดูว่าแพ็กเกจไหนต้องการเวอร์ชันอะไร ตัวเลือกไหนถูกปฏิเสธ และเพราะอะไร

apt / dpkg

sudo tail -n 100 /var/log/apt/history.log
sudo tail -n 100 /var/log/dpkg.log

dnf

sudo journalctl -xe --no-pager | tail -n 100
sudo dnf history

pacman

sudo tail -n 100 /var/log/pacman.log

ลำดับการตรวจสอบแบบใช้งานจริง

ขั้นตอนที่ 1: ตรวจ network และการเข้าถึง repository

ping -c 4 8.8.8.8
ping -c 4 google.com

ขั้นตอนที่ 2: อัปเดตรายการแพ็กเกจ

sudo apt update
sudo dnf makecache
sudo pacman -Syy

ขั้นตอนที่ 3: ซ่อมสถานะที่ค้างอยู่

สำหรับ apt ใช้ dpkg --configure -a, สำหรับ dnf ใช้ dnf check, และสำหรับ pacman ใช้แนวทาง full sync

ขั้นตอนที่ 4: ตรวจเวอร์ชันและแหล่งที่มาของแพ็กเกจที่มีปัญหา

ดูว่าแพ็กเกจมาจาก repository ไหน มีเวอร์ชันอะไรบ้าง และมีตัวไหนถูก hold ไว้หรือไม่

ขั้นตอนที่ 5: สงสัย repository ภายนอกและ config เก่า

dependency error จำนวนมากมีต้นเหตุจริงจาก source ที่ปะปนหรือเก่าเกินไป

สิ่งที่ควรหลีกเลี่ยง

• ติดตั้งแพ็กเกจเพิ่มเติมแบบสุ่มโดยไม่เข้าใจ error
• ดาวน์โหลด .deb / .rpm จากแหล่งที่ไม่น่าเชื่อถือ
• ทำ partial upgrade ต่อไปเรื่อย ๆ
• ปิดการตรวจสอบ signature หรือ dependency
• เพิ่ม repository ภายนอกมากขึ้นทั้งที่ยังไม่รู้สาเหตุจริง

วิธีป้องกันไม่ให้เกิดซ้ำ

• ใช้ repository ทางการเป็นหลัก
• อย่าเก็บ PPA เก่าหรือ source ที่ไม่ถูกต้องไว้
• อย่าหยุดการอัปเดตกลางทาง
• หลีกเลี่ยง partial upgrade ใน Arch
• ทำ snapshot หรือ backup ก่อนเปลี่ยนแปลงครั้งใหญ่

สรุป

เมื่อ Linux ติดตั้งไม่ได้เพราะ dependency error ปัญหามักลึกกว่าการขาด library เพียงตัวเดียว การผสม repository, การอัปเดตที่ถูกขัดจังหวะ, partial upgrade, แพ็กเกจที่ถูก hold, การติดตั้งด้วยมือ และ architecture conflict ล้วนเป็นสาเหตุที่พบได้บ่อย สิ่งสำคัญคืออ่าน error ให้ละเอียด เข้าใจว่าแพ็กเกจไหนต้องการเวอร์ชันอะไร และระบบไม่สามารถให้ได้เพราะเหตุใด จากนั้นจึงใช้แนวทางที่เหมาะกับแต่ละระบบ: dpkg --configure -a และ apt --fix-broken install สำหรับ apt, dnf check และ distro-sync สำหรับ dnf, และ full sync กับ full update สำหรับ pacman