Apa manfaat dari /etc/apt/sources.list.d dibandingkan /etc/apt/sources.list

Saya tahu pertanyaan ini telah ditanyakan sebelumnya, tetapi saya tidak menerima jawaban, "Anda dapat dengan jelas melihat penambahan khusus". Ketika saya menambahkan ppa (yang belum saya lakukan selama bertahun-tahun), saya menekan tombol pada keyboard saya berlabel "Enter" yang memungkinkan saya untuk menambahkan baris kosong sebelum entri baru (saya bahkan akan menambahkan komentar penjelasan, tapi saya seorang penulis teknologi, jadi ....). Saya suka sources.confbersih dan rapi.

/etc/apt/sources.d

Berarti saya punya setengah lusin file untuk diurai, bukan hanya satu.

AFAIK, "sama sekali" tidak ada keuntungan dalam memiliki satu file konfigurasi vs 6 (demi argumen, mungkin Anda memiliki 3 atau bahkan 2, tidak masalah ... 1 masih mengalahkan 2).

Dapatkah seseorang tolong datang dengan keuntungan rasional, "Anda dapat dengan jelas melihat penambahan kustom" adalah alasan orang miskin.

Saya harus menambahkan, saya suka perubahan, HANYA ketika ada manfaat yang diperkenalkan oleh perubahan.

Edit setelah respons pertama:

Itu memungkinkan instalasi baru yang memerlukan repo mereka sendiri untuk tidak harus mencari file flat untuk memastikan bahwa itu tidak menambahkan entri duplikat.

Sekarang, mereka harus mencari direktori untuk dupe daripada file datar. Kecuali mereka menganggap admin tidak mengubah hal-hal ...

Ini memungkinkan administrator sistem untuk dengan mudah menonaktifkan (dengan mengganti nama) atau menghapus (dengan menghapus) set repositori tanpa harus mengedit file monolitik.

Admin harus mencari direktori untuk menemukan file yang sesuai untuk diganti namanya, sebelumnya, ia akan mencari SATU file dan berkomentar satu baris, satu baris untuk "hampir" setiap admin.

Ini memungkinkan pengelola paket untuk memberikan perintah sederhana untuk memperbarui lokasi repositori tanpa harus khawatir secara tidak sengaja mengubah konfigurasi untuk repositori yang tidak terkait.

Saya tidak mengerti yang ini, saya "berasumsi" pengelola paket tahu URL repositori-nya. Sekali lagi, harus ke seddirektori, bukan satu file.

Pada tingkat teknis, sebagai seseorang yang harus menangani perubahan ini dalam beberapa alat info sistem besar dan populer, pada dasarnya turun ke ini:

Untuk sources.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

Perhatikan bahwa kecuali mereka juga melakukan pemeriksaan yang sama seperti di bawah ini, jika Anda telah berkomentar garis repo, tes ini akan salah. Jika mereka melakukan pemeriksaan yang sama seperti di bawah ini, maka kompleksitasnya sama persis, kecuali dilakukan pada banyak file, bukan satu. Juga, kecuali mereka memeriksa SEMUA file yang mungkin, mereka dapat, dan sering melakukannya, menambahkan item duplikat, yang kemudian membuat komplain, hingga Anda menghapus salah satu dari mereka.

Untuk sources.list

# 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 tidak memeriksa keberadaan sumber Google Chrome, dengan mengandalkan nama file yang pasti dibuat oleh paket Chrome mereka untuk hadir. Dalam semua kasus lain, mereka akan membuat file baru di sources.list.d diberi nama persis seperti yang mereka inginkan.

Untuk melihat sumber apa yang Anda miliki, tentu saja, itu tidak begitu cantik, karena Anda tidak bisa lebih mudah membaca dan memelihara daripada:

cat /etc/sources.list

Jadi ini pada dasarnya dilakukan untuk tujuan pembaruan otomatis, dan untuk memberikan perintah tunggal yang mudah yang bisa Anda berikan kepada pengguna, sejauh yang saya tahu. Untuk pengguna, itu berarti bahwa mereka harus membaca banyak file, bukan 1 file untuk melihat apakah mereka memiliki repo yang ditambahkan, dan untuk apt, itu berarti harus membaca banyak file, bukan satu file juga.

Karena di dunia nyata, jika Anda akan melakukan ini dengan baik, Anda harus mendukung pemeriksaan terhadap semua file, terlepas dari apa namanya, dan kemudian menguji apakah tindakan yang akan dilakukan diperlukan atau tidak diperlukan.

Namun, jika Anda tidak akan melakukannya dengan baik, Anda hanya akan mengabaikan cek untuk melihat apakah item tersebut ada di suatu sumber, dan cukup periksa nama file. Saya percaya itulah yang dilakukan sebagian besar hal otomatis, tetapi karena pada akhirnya, saya hanya perlu memeriksa semuanya sehingga saya bisa mendaftar dan bertindak berdasarkan jika salah satu dari file-file itu cocok, satu-satunya hasil nyata membuatnya jauh lebih rumit.

Suntingan Massal

Diberikan menjalankan banyak server, saya akan tergoda untuk hanya skrip pekerjaan malam yang loop melalui /etc/apt/sources.list.d/ dan memeriksa terlebih dahulu untuk memastikan item tersebut tidak ada di sources.list sudah, maka jika sudah tidak, tambahkan item itu ke sources.list, hapus file sources.list.d, dan jika sudah ada di sources.list, hapus saja file sources.list.d

Karena TIDAK ada negatif untuk hanya menggunakan sumber. Daftar di luar kesederhanaan dan kemudahan pemeliharaan, menambahkan sesuatu seperti itu mungkin bukan ide yang buruk, terutama diberikan tindakan acak kreatif oleh admin sistem.

Seperti disebutkan dalam komentar di atas, inxi -r akan dengan rapi mencetak per file repo yang aktif, tetapi tentu saja tidak akan mengedit atau mengubahnya, sehingga hanya setengah dari solusi. Jika banyak distribusi, itu adalah rasa sakit belajar bagaimana masing-masing melakukannya, itu pasti, dan keacakan tentu saja adalah aturan daripada pengecualian dengan sedih.

Memiliki masing-masing repositori (atau kumpulan repositori) di file sendiri membuatnya lebih mudah untuk dikelola, baik secara manual maupun secara terprogram:

• Itu memungkinkan instalasi baru yang memerlukan repo mereka sendiri untuk tidak harus mencari file flat untuk memastikan bahwa itu tidak menambahkan entri duplikat.
• Ini memungkinkan administrator sistem untuk dengan mudah menonaktifkan (dengan mengganti nama) atau menghapus (dengan menghapus) set repositori tanpa harus mengedit file monolitik.
• Ini memungkinkan pengelola paket untuk memberikan perintah sederhana untuk memperbarui lokasi repositori tanpa harus khawatir secara tidak sengaja mengubah konfigurasi untuk repositori yang tidak terkait.

Jika Anda mengelola server secara manual, saya akan menyetujuinya membuat hal-hal lebih membingungkan. Namun, ini menguntungkan manajemen program (yaitu "konfigurasi sebagai kode"). Saat menggunakan perangkat lunak manajemen konfigurasi seperti Puppet, Ansible, Chef, dll., Lebih mudah untuk hanya menjatuhkan atau menghapus file dalam direktori dan jalankan apt update, daripada mem-parsing file untuk menambah atau menghapus baris tertentu.

Terutama karena itu menghindari harus mengelola konten sumber daya 'file' tunggal, misalnya:, /etc/apt/sources.listdari beberapa modul independen yang telah ditulis oleh pihak ketiga.

Saya menghargai penggunaan Ubuntu yang luas dari ".d" dir untuk alasan khusus ini, yaitu sudoers.d, rsyslog.d, sysctl.d., Cron.d, logrotate.d, dll.

Seperti nemo tunjukkan dalam komentar, salah satu keuntungan utama dari sebuah direktori adalah memungkinkan untuk pengertian "kepemilikan".

Distribusi dan penginstal Linux modern semuanya didasarkan pada ide paket - perangkat lunak independen yang dapat, sebanyak mungkin, ditambahkan dan dihapus secara atom. Setiap kali Anda menginstal paket dengan dpkg(dan karenanya apt), ia melacak file mana pada sistem yang dibuat oleh penginstal itu. Menghapus instalasi paket kemudian sebagian besar terdiri dari menghapus file-file itu.

The jawaban yang diterima saat mengambil itu sebagai hal yang buruk bahwa installer Google Chrome diasumsikan bahwa ia hanya harus membuat atau menghapus entri di lokasi itu diharapkan, tapi mengotomatisasi apa lead lain untuk segala macam kasus tepi mengerikan; contohnya:

• Jika ada garis sources.listketika menginstal, tetapi berkomentar, haruskah installer menghapus komentarnya, atau menambahkan duplikat?
• Jika uninstaller menghapus baris, tetapi pengguna telah menambahkan atau mengedit komentar di sebelahnya, file akan dibiarkan dengan komentar yang rusak.
• Jika pengguna menambahkan baris secara manual, penginstal bisa tahu untuk tidak menambahkannya; tapi bagaimana uninstaller tahu tidak menghapusnya?

File terpisah tidak diperlukan untuk kepemilikan; misalnya, penginstal dapat menyertakan blok komentar yang menyatakan bahwa ia "memiliki" serangkaian garis tertentu. Dalam hal ini, ia akan selalu mencari file untuk blok yang tepat itu, bukan untuk menyebutkan lain dari repositori yang sama.

Semua yang lain sama, mengotomatiskan pengeditan ke file konfigurasi tunggal akan selalu lebih rumit daripada mengotomatisasi pembuatan dan penghapusan file terpisah. Paling tidak, menghapus garis membutuhkan penggunaan beberapa alat pencocokan pola sepertised . Dalam file yang lebih kompleks, baik menambah dan menghapus baris mungkin memerlukan alat skrip dengan pengetahuan tentang format file, untuk menambah bagian yang sesuai, atau menghapus tanpa merusak format sekitarnya.

Karena penginstal perlu menghindari mengacaukan konfigurasi yang diedit secara manual, masuk akal untuk menempatkan konfigurasi otomatis yang dimiliki alat dalam format yang mudah dikelola oleh alat otomatis.

Ini memungkinkan paket untuk menambahkan sumber tambahan tanpa menggunakan skrip.

Misalnya, ketika Anda menginstal paket Skype Microsoft, sumber untuk skype.com secara otomatis dikonfigurasi untuk mengunduh pembaruan; menghapus paket Skype dari sistem juga menonaktifkan sumber paket ini lagi.

Jika Anda ingin memiliki efek yang sama dengan file flat, maka skrip instalasi untuk Skype akan perlu memodifikasi sumber Anda.

Saya tidak yakin bahwa ada alasan yang bagus - selain tampaknya modis. Bagi saya, itu melanggar aturan bahwa direktori harus berupa daun atau simpul - yaitu bahwa direktori tersebut seharusnya hanya berisi file atau direktori, bukan campuran keduanya.

Saya kira itu membuat file lebih kecil, jadi lebih mudah dibaca - dalam kasus misalnya aturan sudo, yang bisa sangat lama, itu membuatnya lebih mudah untuk memiliki seperangkat aturan standar untuk satu jenis pengguna (katakanlah pengembang ), dan tambahkan itu ke direktori config jika devs bolehkan sudo pada mesin ini; jadi Anda perlu memelihara lebih sedikit file - hanya file untuk devs, untuk admin, untuk sysop, dll, daripada untuk setiap kemungkinan kombinasi darinya.

Di sana, saya telah membantah diri saya sendiri.