ประโยชน์ของ /etc/apt/sources.list.d มากกว่า /etc/apt/sources.list คืออะไร

ฉันรู้ว่าคำถามนี้ถูกถามมาก่อน แต่ฉันไม่ยอมรับคำตอบ "คุณสามารถเห็นการเพิ่มที่กำหนดเองได้อย่างชัดเจน" เมื่อฉันเพิ่ม ppa (ซึ่งฉันยังไม่ได้ทำในปี) ฉันกดปุ่มบนแป้นพิมพ์ของฉันที่มีข้อความ "Enter" ซึ่งทำให้ฉันสามารถเพิ่มบรรทัดว่างก่อนรายการใหม่ (ฉันจะเพิ่มความคิดเห็นอธิบาย แต่ฉันเป็น นักเขียนเทคโนโลยีดังนั้น .... ) ฉันชอบที่sources.confสะอาดและเรียบร้อย

/etc/apt/sources.d

หมายความว่าฉันมีไฟล์ครึ่งโหลในการแยกวิเคราะห์แทนที่จะเป็นไฟล์เดียว

AFAIK มี "แน่นอน" ไม่มีประโยชน์ในการมีหนึ่งไฟล์การกำหนดค่าเทียบกับ 6 (เพื่อประโยชน์ในการโต้แย้งบางทีคุณมี 3 หรือแม้กระทั่ง 2 ไม่สำคัญ ... 1 ยังคงเต้น 2)

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

ฉันต้องเพิ่มฉันรักการเปลี่ยนแปลงอย่างไรก็ตามเฉพาะเมื่อมีประโยชน์ที่ได้รับการแนะนำจากการเปลี่ยนแปลง

แก้ไขหลังจากตอบกลับครั้งแรก:

อนุญาตให้ติดตั้งใหม่ที่ต้องการ repos ของตัวเองไม่ต้องค้นหาไฟล์แฟลตเพื่อให้แน่ใจว่ามันจะไม่เพิ่มรายการที่ซ้ำกัน

ตอนนี้พวกเขาต้องค้นหาไดเร็กทอรีของ dupe แทนที่จะเป็นไฟล์ flat หากพวกเขาไม่คิดว่าผู้ดูแลระบบจะไม่เปลี่ยนแปลงสิ่งต่าง ๆ ...

อนุญาตให้ผู้ดูแลระบบปิดการใช้งาน (โดยการเปลี่ยนชื่อ) หรือลบ (โดยการลบ) ชุดที่เก็บโดยไม่ต้องแก้ไขไฟล์เสาหิน

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

ช่วยให้ผู้ดูแลแพคเกจให้คำสั่งง่าย ๆ ในการอัปเดตตำแหน่งที่เก็บโดยไม่ต้องกังวลกับการเปลี่ยนการกำหนดค่าสำหรับที่เก็บที่ไม่เกี่ยวข้องโดยไม่ตั้งใจ

ฉันไม่เข้าใจอันนี้ฉัน "ถือว่า" ผู้ดูแลแพคเกจรู้ URL ของที่เก็บของเขา อีกครั้งมีsedไดเรกทอรีแทนไฟล์เดียว

ในระดับเทคนิคในฐานะคนที่ต้องจัดการกับการเปลี่ยนแปลงเหล่านี้ในเครื่องมือข้อมูลระบบที่มีขนาดใหญ่และได้รับความนิยมไม่กี่ตัว

สำหรับ source.list.d /

# to add
if [[ ! -e /etc/apt/sources.list.d/some_repo.list ]];then
  echo 'some repo line for apt' > /etc/apt/sources.list.d/some_repo.list
fi

# to delete
if [[ -e /etc/apt/sources.list.d/some_repo.list ]];then
  rm -f /etc/apt/sources.list.d/some_repo.list
fi

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

สำหรับแหล่งรายการ

# to add. Respect commented out lines. Bonus points for uncommenting
# line instead of adding a new line
if [[ -z $( grep -E '\s*[^#]\s*some repo line for apt' /etc/apt/sources.list ) ]];then
  echo 'some repo line for apt' >> /etc/apt/sources.list
fi

# to delete. Delete whether commented out or not. Bonus for not
# deleting if commented out, thus respecting the user's wishes
sed -i '/.*some repo line for apt.*/d' /etc/apt/sources.list

Google Chrome devs ไม่ได้ตรวจสอบว่ามีแหล่งที่มาของ Google Chrome อยู่หรือไม่โดยอาศัยชื่อไฟล์ที่แน่นอนที่แพ็คเกจ Chrome ของพวกเขาจะสร้างขึ้นมา ในกรณีอื่น ๆ พวกเขาจะสร้างไฟล์ใหม่ใน source.list.d ตั้งชื่อตามที่พวกเขาต้องการ

หากต้องการดูแหล่งที่มาของคุณแน่นอนว่ามันไม่ได้สวยมากนักเนื่องจากคุณไม่สามารถอ่านและดูแลได้ง่ายกว่า:

cat /etc/sources.list

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

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

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

การแก้ไขเป็นกลุ่ม

เมื่อใช้เซิร์ฟเวอร์หลายเครื่องฉันจะถูกล่อลวงให้เขียนสคริปต์งานยามค่ำคืนที่วนผ่าน /etc/apt/sources.list.d/ และตรวจสอบก่อนเพื่อให้แน่ใจว่ารายการนั้นไม่ได้อยู่ในแหล่งรายการแล้วถ้าเป็น ไม่เพิ่มรายการนั้นไปที่ sources.list ลบไฟล์ sources.list.d และหากอยู่ในแหล่งรายการแล้วให้ลบไฟล์ sources.list.d

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

ดังที่ระบุไว้ในความคิดเห็นข้างต้น inxi -r จะพิมพ์ repos ที่ใช้งานอยู่อย่างประณีตต่อไฟล์ แต่จะไม่แก้ไขหรือดัดแปลงแน่นอนดังนั้นจะเป็นเพียงครึ่งหนึ่งของการแก้ปัญหา หากมีการแจกแจงจำนวนมากมันเป็นความเจ็บปวดในการเรียนรู้ว่าแต่ละคนทำได้อย่างไรและแน่นอนว่าการสุ่มนั้นเป็นกฎแทนที่จะเป็นเรื่องที่น่าเศร้า

การมีที่เก็บแต่ละอัน (หรือที่เก็บของที่เก็บ) ไว้ในไฟล์ของตัวเองทำให้จัดการได้ง่ายขึ้นทั้งด้วยมือและโดยทางโปรแกรม:

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

หากคุณจัดการเซิร์ฟเวอร์ของคุณด้วยตนเองฉันจะยอมรับมันทำให้เกิดความสับสนมากขึ้น อย่างไรก็ตามมันเป็นประโยชน์ต่อการจัดการแบบเป็นโปรแกรม (เช่น "การกำหนดค่าเป็นรหัส") เมื่อใช้ซอฟต์แวร์การจัดการการกำหนดค่าเช่น Puppet, Ansible, Chef เป็นต้นง่ายกว่าที่จะวางหรือลบไฟล์ใน dir แล้วรันapt updateแทนที่จะแยกวิเคราะห์ไฟล์เพื่อเพิ่มหรือลบบางบรรทัด

โดยเฉพาะอย่างยิ่งตั้งแต่ที่หลีกเลี่ยงการจัดการเนื้อหาของทรัพยากร 'ไฟล์' เดียวเช่น: /etc/apt/sources.listจากโมดูลอิสระหลายที่เขียนโดยบุคคลที่สาม

ฉันขอขอบคุณที่ใช้อย่างแพร่หลายของ ".d" dirs ด้วยเหตุผลนี้เช่น sudoers.d, rsyslog.d, sysctl.d., cron.d, logrotate.d เป็นต้น

ในฐานะที่เป็นnemoชี้ให้เห็นในความคิดเห็นหนึ่งในข้อดีที่สำคัญของไดเรกทอรีคือมันช่วยให้แนวคิดของ "ความเป็นเจ้าของ"

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

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

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

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

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

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

สิ่งนี้ช่วยให้แพคเกจเพื่อเพิ่มแหล่งข้อมูลพิเศษโดยไม่ต้องหันไปใช้สคริปต์

ตัวอย่างเช่นเมื่อคุณติดตั้งแพคเกจ Skype ของ Microsoft แหล่งที่มาสำหรับ skype.com จะได้รับการกำหนดค่าให้ดาวน์โหลดการอัพเดตโดยอัตโนมัติ การนำแพคเกจ Skype ออกจากระบบยังปิดใช้งานแหล่งแพ็กเกจนี้อีกครั้ง

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

ฉันไม่เชื่อว่ามีเหตุผลที่ดี - นอกเหนือไปจากแฟชั่น สำหรับฉันมันแบ่งกฎที่ไดเรกทอรีควรเป็นใบไม้หรือโหนด - นั่นคือควรมีเฉพาะไฟล์หรือไดเรกทอรีไม่ใช่ส่วนผสมของทั้งสอง

ฉันคิดว่ามันทำให้ไฟล์เล็กลงอ่านง่ายขึ้น - ในกรณีของกฎ sudo ซึ่งอาจใช้เวลานานมันทำให้ง่ายขึ้นที่จะมีกฎชุดมาตรฐานสำหรับผู้ใช้ประเภทหนึ่ง (พูดนักพัฒนา) ) และเพิ่มสิ่งเหล่านั้นในไดเร็กทอรี config หาก devs ควรได้รับอนุญาตให้ sudo บนเครื่องนี้; ดังนั้นคุณต้องรักษาไฟล์ให้น้อยลง - เพียงแค่ไฟล์สำหรับ devs สำหรับผู้ดูแลระบบสำหรับ sysops ฯลฯ แทนที่จะเป็นชุดค่าผสมที่เป็นไปได้ทั้งหมด

ที่นั่นฉันได้ขัดแย้งกับตัวเอง