Cela dépend de la distribution et de la source d'origine ("en amont").
Avec la plupart des packages utilisant autoconf et automake, il est possible de spécifier le répertoire où les fichiers de configuration seront recherchés en utilisant le --sysconfdir paramètre. D'autres systèmes de construction (par exemple, CMake) ont des options similaires. Si le paquet source utilise l'un de ces systèmes de construction, le conditionneur peut facilement spécifier les bons paramètres et aucun correctif n'est requis. Même s'ils ne le font pas (par exemple, parce que la source en amont utilise un système de construction maison), il est souvent toujours possible de spécifier une configuration de construction pour déplacer les fichiers de configuration vers un emplacement particulier sans avoir à patcher la source en amont.
Si ce n'est pas le cas, la distribution devra souvent ajouter des correctifs à la source pour lui faire déplacer les fichiers dans ce qu'elle considère être le « bon » emplacement. Dans la plupart des cas, les empaqueteurs de distribution écriront alors un patch qui permettra à la source d'être configurée dans le sens ci-dessus, afin qu'ils puissent envoyer le patch aux mainteneurs en amont, et n'aient pas à le maintenir/le mettre à jour. C'est le cas pour les emplacements des fichiers de configuration, mais aussi pour d'autres choses, comme le bin /sbin exécutables (l'interprétation de ce qu'est la commande d'un administrateur système diffère d'une distribution à l'autre), emplacement où écrire la documentation, etc.
Remarque :si vous maintenez des logiciels libres, s'il vous plaît permettre aux emballeurs de vous parler facilement. Sinon, nous devons maintenir ces correctifs sans raison particulièrement valable...
Ils ont des correctifs appliqués à l'arborescence du code source qui adaptent les emplacements.
Il existe suffisamment de "normes" disponibles pour que chaque distribution puisse faire son choix en fonction de ses préférences (personnelles) et/ou de ses pratiques historiques. Il existe rarement une solution qui uniquement a des avantages. C'est parfois ennuyeux/déroutant, mais la cohérence au sein d'une distribution est l'objectif le plus important :cela conduit à moins d'encombrement et à deviner plus facilement où les choses pourraient être pour le programme Y si vous savez déjà où des choses similaires (fichiers d'installation/configuration par exemple) sont pour le programme X.
Exemple d'application de correctif
Mon paquet python ruamel.yaml est disponible dans Debian Sid. Il dépendait de ruamel.base , et les utilisateurs qui ont installé via PyPI peuvent encore avoir des versions plus anciennes et incompatibles de ruamel.base installée. Utilisation de setup.py /PyPI n'est pas une véritable gestion de paquets, vous ne pouvez donc pas supprimer un paquet précédemment installé via des dépendances. J'ai résolu le problème pour les utilisateurs de PyPI en créant une nouvelle version de ruamel.base qui a supprimé les problèmes associés à l'ancien ruamel.base paquets et fait ruamel.yaml dépend de cette version plus récente.
Pour Sid, ce n'est pas un problème :anciennes versions de ruamel.base n'étaient pas installés (ou pouvaient être supprimés via la gestion des packages). Par conséquent, ils appliquent un correctif, que vous pouvez trouver sur le ruamel.yaml page d'informations pour Sid qui supprime la dépendance de ruamel.yaml sur ruamel.base .
D'autres distributions ont des configurations similaires. Par exemple. Si vous regardez les spécifications de création d'un fichier RPM source (par exemple pour RedHat/CentOS/SuSE), vous verrez que vous combinez l'archive tar d'origine d'un paquet avec un ou plusieurs correctifs qui seront appliqués avant la configuration/compilation.