Dipende dalla distribuzione e dalla fonte originale ("upstream").
Con la maggior parte dei pacchetti che utilizzano autoconf e automake, è possibile specificare la directory in cui verranno cercati i file di configurazione utilizzando --sysconfdir parametro. Altri sistemi di compilazione (ad esempio CMake) hanno opzioni simili. Se il pacchetto sorgente utilizza uno di questi sistemi di compilazione, il creatore di pacchetti può facilmente specificare i parametri corretti e non sono necessarie patch. Anche se non lo fanno (ad esempio, perché la sorgente originale utilizza un sistema di compilazione sviluppato internamente), è spesso ancora possibile specificare una configurazione di compilazione per spostare i file di configurazione in una posizione particolare senza dover applicare una patch alla sorgente originale.
In caso contrario, spesso la distribuzione dovrà effettivamente aggiungere patch alla fonte per far spostare i file in quella che considerano la posizione "giusta". Nella maggior parte dei casi, i pacchettizzatori della distribuzione scriveranno quindi una patch che consentirà di configurare il sorgente nel senso sopra indicato, in modo che possano inviare la patch ai manutentori a monte e non debbano continuare a mantenerla/aggiornarla. Questo è il caso delle posizioni dei file di configurazione, ma anche di altre cose, come bin /sbin eseguibili (l'interpretazione di ciò che è il comando di un amministratore di sistema differisce tra le distribuzioni), la posizione in cui scrivere la documentazione e così via.
Nota a margine:se mantieni del software libero, per favore rendere facile per i confezionatori parlare con te. Altrimenti dobbiamo mantenere tali patch senza una ragione particolarmente valida...
Hanno patch applicate all'albero del codice sorgente che adattano le posizioni.
Ci sono abbastanza "standard" disponibili che ogni distribuzione può scegliere in base a preferenze (personali) e/o pratiche storiche. Raramente c'è una soluzione che solo ha dei vantaggi. Questo a volte è fastidioso/confuso, ma la coerenza all'interno di una distribuzione è l'obiettivo più importante:porta a meno disordine e a indovinare più facilmente dove potrebbero essere le cose per il programma Y se sai già dove sono cose simili (file di installazione/configurazione ad esempio) per il programma X.
Esempio di applicazione patch
Il mio pacchetto Python ruamel.yaml è disponibile in Debian Sid. Prima dipendeva da ruamel.base e gli utenti che hanno installato tramite PyPI potrebbero ancora avere versioni precedenti e incompatibili di ruamel.base installato. Usando setup.py /PyPI non è una vera gestione dei pacchetti, quindi non puoi eliminare un pacchetto precedentemente installato tramite dipendenze. Ho risolto il problema per gli utenti PyPI creando una versione più recente di ruamel.base che ha rimosso i problemi associati al vecchio ruamel.base packages e ha creato ruamel.yaml dipende dalla versione più recente.
Per Sid questo non è un problema:versioni precedenti di ruamel.base non sono stati installati (o potrebbero essere rimossi tramite la gestione dei pacchetti). Pertanto applicano una patch, che puoi trovare sul ruamel.yaml pagina di informazioni per Sid che rimuove la dipendenza di ruamel.yaml su ruamel.base .
Altre distribuzioni hanno configurazioni simili. Per esempio. se guardi le specifiche della creazione di un file RPM sorgente (ad esempio per RedHat/CentOS/SuSE), vedrai che combini il tarball originale originale di un pacchetto con una o più patch che verranno applicate prima della configurazione/compilazione.