Avere ogni repository (o raccolta di repository) nel proprio file rende più semplice la gestione, sia manualmente che a livello di programmazione:
- Consente alle nuove installazioni che necessitano dei propri repository di non dover cercare un file flat per assicurarsi che non aggiunga voci duplicate.
- Consente a un amministratore di sistema di disabilitare facilmente (rinominando) o rimuovere (eliminando) un set di repository senza dover modificare un file monolitico.
- Consente a un manutentore di pacchetti di dare un semplice comando per aggiornare le posizioni dei repository senza doversi preoccupare di modificare inavvertitamente la configurazione per repository non correlati.
A livello tecnico, come qualcuno che ha dovuto gestire questi cambiamenti in alcuni strumenti di informazioni di sistema grandi e popolari, sostanzialmente si riduce a questo:
Per fonti.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
Nota che, a meno che non stiano eseguendo anche lo stesso controllo di seguito, se avessi commentato una riga di repository, questi test sarebbero sbagliati. Se stanno eseguendo lo stesso controllo di seguito, è la stessa identica complessità, tranne che eseguito su molti file, non su uno. Inoltre, a meno che non stiano controllando TUTTI i file possibili, possono, e spesso lo fanno, aggiungere un elemento duplicato, il che fa sì che si lamentino, fino a quando non ne elimini uno.
Per fonti.elenco
# 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
Gli sviluppatori di Google Chrome non hanno verificato la presenza delle fonti di Google Chrome, basandosi sul nome esatto del file che il loro pacchetto Chrome avrebbe creato per essere presente. In tutti gli altri casi, creerebbero un nuovo file in sources.list.d chiamato esattamente come volevano.
Per vedere quali fonti hai, ovviamente, non è così carino, dal momento che non puoi essere più facile da leggere e mantenere di:
cat /etc/sources.list
Quindi questo è stato sostanzialmente fatto ai fini degli aggiornamenti automatici e per fornire semplici comandi singoli che potresti dare agli utenti, per quanto ne so. Per gli utenti, significa che devono leggere molti file invece di 1 file per vedere se hanno aggiunto un repository e, per apt, significa che deve leggere anche molti file invece di un file.
Dal momento che nel mondo reale, se hai intenzione di farlo bene, devi supportare i controlli su tutti i file, indipendentemente dal loro nome, e quindi verificare se l'azione da eseguire è richiesta o meno.
Tuttavia, se non lo facessi bene, ignoreresti semplicemente i controlli per vedere se l'elemento si trova da qualche parte nelle fonti e controlleresti solo il nome del file. Credo che sia ciò che fa la maggior parte delle cose automatizzate, ma poiché alla fine dovevo semplicemente controllare tutto in modo da poterlo elencare e agire in base alla corrispondenza di uno di quei file, l'unico vero risultato è stato renderlo molto più complicato.
Modifiche collettive
Dato l'esecuzione di molti server, sarei tentato di scrivere solo un lavoro notturno che scorre /etc/apt/sources.list.d/ e controlla prima per assicurarsi che l'elemento non sia già in sources.list, quindi se lo è no, aggiungi quell'elemento a sources.list, cancella il file sources.list.d, e se sei già in sources.list, cancella solo il file sources.list.d
Dal momento che NON c'è nulla di negativo nell'usare solo sources.list oltre alla semplicità e alla facilità di manutenzione, aggiungere qualcosa del genere potrebbe non essere una cattiva idea, in particolare date le azioni casuali creative degli amministratori di sistema.
Come notato nel commento sopra, inxi -r stamperà ordinatamente per file i repository attivi, ma ovviamente non li modificherà o altererà, quindi sarebbe solo metà della soluzione. Se ci sono molte distribuzioni, è una seccatura imparare come ciascuna lo fa, questo è certo, e purtroppo la casualità è certamente la regola piuttosto che l'eccezione.
Se gestisci manualmente i tuoi server, sono d'accordo che rende le cose più confuse. Tuttavia, avvantaggia la gestione programmatica (ovvero "configurazione come codice"). Quando si utilizza un software di gestione della configurazione come Puppet, Ansible, Chef, ecc., è più semplice trascinare o rimuovere un file in una directory ed eseguire apt update , invece di analizzare un file per aggiungere o rimuovere determinate righe.
Tanto più che ciò evita di dover gestire il contenuto di una singola risorsa 'file', ad esempio:/etc/apt/sources.list , da più moduli indipendenti che sono stati scritti da terze parti.
Apprezzo l'ampio uso di Ubuntu delle directory ".d" per questo particolare motivo, ad esempio sudoers.d, rsyslog.d, sysctl.d., cron.d, logrotate.d, ecc.