Qu'est-ce que $ RPM_BUILD_ROOT en réalité?
Dans le processus de construction d'un package RPM, je dois spécifier le BuildRoot et plus tard sera utilisé dans% install qui invoite $ RPM_BUILD_ROOT. Je pense toujours que $ RPM_BUILD_ROOT est la fausse installation pour que RPM effectue l'empaquetage. Ensuite, au moment de l'installation à l'aide du package RPM, il sera installé à l'emplacement réel. Par exemple:
$RPM_BUILD_ROOT/usr/bin
Je pensais que $ RPM_BUILD_ROOT est uniquement pour le processus de conditionnement, et à certains égards, RPM peut distinguer $ RPM_BUILD_ROOT et l'emplacement d'installation réel lorsque l'utilisateur exécute "rpm -ivh package.rpm" sera/usr/bin.
Mais récemment, à la lecture de certains documents, il est suggéré que $ RPM_BUILD_ROOT est l'emplacement réel qui sera installé, et la $ RPM_BUILD_ROOT est spécifiée par l'utilisateur avec le paramètre de la variable d'environnement $ RPM_BUILD_ROOT afin de permettre aux utilisateurs d'installer le package à leur guise Emplacements. Sinon, $ RPM_BUILD_ROOT sera nul et il s'installera à l'emplacement par défaut. Dans le cas ci-dessus, il s'agit de/usr/bin. Ainsi, $ RPM_BUILD_ROOT n'est pas seulement destiné à l'empaquetage ou au processus de "fausse installation", mais est un moyen pour l'utilisateur de définir l'emplacement d'installation, similaire à sélectionner l'emplacement du dossier dans Windows.
Je ne sais pas si ma pensée est correcte ou non. Quelqu'un peut-il vérifier? Merci d'avance.
$RPM_BUILD_ROOT (ou l'équivalent %{buildroot} Macro de fichier SPEC) toujours contient le répertoire dans lequel RPM recherchera les fichiers à empaqueter. Les scripts RPM (par exemple le script qui compresse les pages de manuel) utiliseront également cette valeur pour savoir où rechercher les fichiers qui viennent d'être installés. Normalement, cette valeur sera non vide et contiendra un emplacement éloigné des répertoires système - généralement quelque part sous /tmp ou /var/tmp.
L'auteur du fichier SPEC doit s'assurer que make install (ou tout programme d'installation que le logiciel en question utilise) placera tous les fichiers sous $RPM_BUILD_ROOT, avec la même hiérarchie qui devrait être utilisée lors de l'installation finale du logiciel. Par exemple. pour que RPM installe ls dans /bin/ls, les %install La section du fichier SPEC doit s'assurer que ls est placé dans $RPM_BUILD_ROOT/bin/ls.
L'auteur du fichier SPEC devrait également utiliser le BuildRoot: tag pour spécifier un emplacement approprié. Alternativement, le système de construction pourrait avoir un fichier de configuration rpmrc RPM avec une entrée appropriée. Dans dans tous les cas la racine de construction doit être définie, de sorte que:
Les utilisateurs normaux pourront créer le package source.
Si le superutilisateur crée le package source, le processus de génération n'encombrera aucun fichier système, sauf si le superutilisateur installe le package binaire résultant. Et oui, il peut y avoir une bonne raison de construire certains packages en tant que
root- par exemple, en exécutant leglibctestsuite nécessite des privilègesrootpour certains tests.
Cela dit, RPM peut et va construire un package avec une variable racine de build vide. Dans ce cas, l'installation de build et les emplacements de destination finale coïncideront. Un appel potentiel à par exemple make install utilisera les emplacements par défaut, encombrant ainsi les fichiers système sous par ex. /usr/lib si exécuté avec des privilèges suffisants. De plus, avoir /usr/bin/* dans votre %files la section tirera avec plaisir tout le contenu de l'hôte de construction /usr/bin/ répertoire dans votre package binaire.
Conclusion:
N'utilisez jamais une racine de build vide.
Ne construisez pas de packages en tant que
rootsauf s'il n'y a absolument aucun autre moyen.
le fichier ~/.rpmmacros définit les chemins par utilisateur:
%_topdir %(echo $HOME)/rpmbuild
%_tmppath %{_topdir}/tmp
et on peut également les définir avec les paramètres de ligne de commande rpmbuild:
rpmbuild --define '_topdir /home/username/rpmbuild'