Qual è il vantaggio di /etc/apt/sources.list.d rispetto a /etc/apt/sources.list

So che questa domanda è stata posta prima, ma non accetto la risposta "puoi vedere chiaramente aggiunte personalizzate". Quando aggiungo ppa (che non faccio da anni), premo un tasto sulla tastiera con l'etichetta "Invio" che mi consente di aggiungere una riga vuota prima della nuova voce (aggiungerei anche un commento esplicativo, ma sono un scrittore tecnico, quindi ....). Mi piace il mio sources.confpulito e ordinato.

/etc/apt/sources.d

Significa che ho una mezza dozzina di file da analizzare anziché solo uno.

AFAIK, non c'è "assolutamente" alcun vantaggio nell'avere un file di configurazione contro 6 (per amor di discussione, forse hai 3 o anche 2, non importa ... 1 batte ancora 2).

Qualcuno può, per favore, presentare un vantaggio razionale, "puoi vedere chiaramente aggiunte personalizzate" è la scusa di un uomo povero.

Devo aggiungere, adoro il cambiamento, tuttavia, SOLO quando ci sono vantaggi introdotti dal cambiamento.

Modifica dopo la prima risposta:

Permette alle nuove installazioni che richiedono i propri repository di non dover cercare un file flat per assicurarsi che non stia aggiungendo voci duplicate.

Ora devono cercare in una directory i file duplicati anziché un file flat. A meno che non presumano che l'amministratore non cambi le cose ...

Consente a un amministratore di sistema di disabilitare facilmente (rinominando) o rimuovere (eliminando) un set di repository senza dover modificare un file monolitico.

L'amministratore deve grep directory per trovare il file appropriato per rinominare, prima, avrebbe cercato UN file e commentato una riga, un sed one-liner per "quasi" qualsiasi amministratore.

Consente a un manutentore di pacchetti di fornire un semplice comando per aggiornare le posizioni dei repository senza doversi preoccupare di modificare inavvertitamente la configurazione per repository non correlati.

Non capisco questo, "presumo" che il manutentore del pacchetto conosca l'URL del suo repository. Ancora una volta, deve seduna directory anziché un singolo file.

A livello tecnico, come qualcuno che ha dovuto gestire queste modifiche in alcuni strumenti di informazioni di sistema di grandi dimensioni e popolari, fondamentalmente si riduce a questo:

Per 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

Si noti che a meno che non stiano eseguendo lo stesso controllo di seguito, se si fosse commentato una riga di repository, questi test sarebbero errati. Se stanno facendo lo stesso controllo di seguito, allora è la stessa esatta complessità, fatta eccezione per molti file, non uno. Inoltre, a meno che non stiano controllando TUTTI i file possibili, possono, e spesso lo fanno, aggiungere un elemento duplicato, che quindi fa lamentare apt, fino a quando non ne elimini uno.

Per 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

Gli sviluppatori di Google Chrome non hanno verificato la presenza di 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, avrebbero creato un nuovo file in sources.list.d chiamato esattamente come volevano.

Per vedere quali fonti hai, ovviamente, non è così bello, dal momento che non puoi essere più facile da leggere e mantenere di:

cat /etc/sources.list

Quindi, ciò è 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 anziché un solo file.

Dal momento che nel mondo reale, se avessi intenzione di farlo bene, devi supportare i controlli su tutti i file, indipendentemente da come sono stati nominati, e quindi verificare se l'azione da eseguire è richiesta o meno.

Tuttavia, se non lo avessi fatto bene, ignoreresti semplicemente i controlli per vedere se l'elemento si trova da qualche parte nelle fonti e verifichi semplicemente il nome del file. Credo che sia quello che fa la maggior parte delle cose automatizzate, ma dato che alla fine, ho dovuto semplicemente controllare tutto per 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 che esegue molti server, sarei tentato di scrivere un lavoro notturno che scorre in /etc/apt/sources.list.d/ e controlla prima che l'elemento non sia già in sources.list, quindi se lo è no, aggiungi quell'elemento a sources.list, elimina il file sources.list.d e, se già in sources.list, elimina semplicemente il file sources.list.d

Dal momento che NON c'è NESSUNA negligenza nell'usare solo le fonti. Oltre la semplicità e la facilità di manutenzione, aggiungere qualcosa del genere potrebbe non essere una cattiva idea, in particolare date azioni casuali creative da parte degli amministratori di sistema.

Come notato nel commento sopra, inxi -r stamperà ordinatamente per file i repository attivi, ma ovviamente non li modificherà o li altererà, quindi sarebbe solo metà della soluzione. Se sono molte le distribuzioni, è un dolore imparare come ognuna lo fa, questo è certo, e la casualità è certamente la regola piuttosto che l'eccezione tristemente.

Avere ogni repository (o raccolta di repository) nel proprio file rende più semplice la gestione, sia a mano che a livello di programmazione:

• Permette alle nuove installazioni che richiedono i propri repository di non dover cercare un file flat per assicurarsi che non stia aggiungendo 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 fornire un semplice comando per aggiornare le posizioni dei repository senza doversi preoccupare di modificare inavvertitamente la configurazione per repository non correlati.

Se gestisci manualmente i tuoi server, concordo 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 rilasciare o rimuovere un file in una directory ed eseguirlo apt update, invece di analizzare un file per aggiungere o rimuovere determinate linee.

Soprattutto perché evita di dover gestire il contenuto di una singola risorsa "file", ad esempio: /etc/apt/sources.listda più moduli indipendenti che sono stati scritti da terze parti.

Apprezzo l'ampio uso da parte di Ubuntu di ".d" dirs per questo motivo particolare, ad esempio sudoers.d, rsyslog.d, sysctl.d., Cron.d, logrotate.d, ecc.

Come ha sottolineato nemo in un commento, uno dei principali vantaggi di una directory è che consente di definire "proprietà".

Le moderne distribuzioni e programmi di installazione di Linux sono tutte basate sull'idea di pacchetti : software indipendenti che possono, per quanto possibile, essere aggiunti e rimossi atomicamente. Ogni volta che installi un pacchetto con dpkg(e quindi apt), tiene traccia di quali file sul sistema sono stati creati da quel programma di installazione. La disinstallazione del pacchetto può quindi consistere in gran parte nell'eliminazione di tali file.

La risposta attualmente accettata lo considera un fatto negativo che un installatore di Google Chrome ha ipotizzato che dovesse solo creare o eliminare una voce nella posizione prevista, ma automatizzare qualsiasi altra cosa porta a tutti i tipi di orribili casi limite; per esempio:

• Se la linea esiste sources.listdurante l'installazione, ma è commentata, il programma di installazione dovrebbe decommentarla o aggiungere un duplicato?
• Se il programma di disinstallazione rimuove la riga, ma l'utente ha aggiunto o modificato i commenti accanto, il file verrà lasciato con commenti non funzionanti.
• Se l'utente aggiungesse manualmente la linea, l'installatore poteva sapere di non aggiungerla; ma come potrebbe sapere il programma di disinstallazione di non rimuoverlo?

Non sono richiesti file separati per la proprietà; ad esempio, il programma di installazione potrebbe includere un blocco di commenti che afferma che "possiede" un determinato insieme di righe. In tal caso, cercherebbe sempre nel file quel blocco esatto, non qualche altra menzione dello stesso repository.

A parità di tutti gli altri aspetti, l'automazione delle modifiche in un singolo file di configurazione sarà sempre più complicata rispetto all'automazione della creazione e della cancellazione di un file separato. Per lo meno, la rimozione delle linee richiede l'uso di alcuni strumenti di corrispondenza dei modelli come sed. In un file più complesso, sia l'aggiunta che la rimozione di righe potrebbe richiedere uno strumento di scripting con conoscenza del formato del file, da aggiungere a una sezione appropriata o da rimuovere senza danneggiare la formattazione circostante.

Dato che un installatore dovrebbe comunque evitare di fare confusione con la configurazione modificata manualmente, ha senso mettere la configurazione automatizzata, di proprietà degli strumenti, in un formato facile da gestire per gli strumenti automatizzati.

Ciò consente ai pacchetti di aggiungere ulteriori fonti senza ricorrere agli script.

Ad esempio, quando si installa il pacchetto Skype di Microsoft, una fonte per skype.com viene automaticamente configurata per il download degli aggiornamenti; la rimozione del pacchetto Skype dal sistema disabilita nuovamente questa fonte del pacchetto.

Se vuoi avere lo stesso effetto con un file flat, gli script di installazione per Skype dovrebbero modificare il tuo sources.list, che probabilmente molti amministratori di sistema riterrebbero leggermente snervante.

Non sono convinto che ci sia una buona ragione - a parte che sembra di moda. Per me, infrange una regola secondo cui una directory dovrebbe essere una foglia o un nodo - cioè che dovrebbe contenere solo file o directory, non una combinazione di entrambi.

Suppongo che renda i file più piccoli, quindi più facili da leggere - nel caso, ad esempio, delle regole sudo, che possono essere piuttosto lunghe, rende più semplice avere un set standardizzato di regole per un tipo di utente (ad esempio uno sviluppatore ) e aggiungerli alla directory di configurazione se gli sviluppatori devono poter eseguire il sudo su questa macchina; quindi è necessario mantenere un minor numero di file - solo un file per sviluppatori, amministratori, sysops, ecc., piuttosto che per ogni possibile combinazione di questi.

Lì, mi sono contraddetto.