linux - ¿Qué es en realidad $ RPM_BUILD_ROOT?

packaging (2)

El archivo ~ / .rpmmacros define las rutas por usuario:

%_topdir %(echo $HOME)/rpmbuild %_tmppath %{_topdir}/tmp

y uno también puede definirlos con los parámetros de la línea de comando rpmbuild:

rpmbuild --define ''_topdir /home/username/rpmbuild''

En el proceso de compilación de un paquete RPM, tengo que especificar BuildRoot y luego se usará en% install que incluye $ RPM_BUILD_ROOT. Siempre pienso que $ RPM_BUILD_ROOT es la instalación falsa para que RPM realice el empaquetado. Luego, en el momento de la instalación con el paquete RPM, se instalará en la ubicación real. Por ejemplo:

$RPM_BUILD_ROOT/usr/bin

Pensé que $ RPM_BUILD_ROOT es solo para el proceso de empaquetado, y de alguna manera RPM puede distinguir el $ RPM_BUILD_ROOT y la ubicación de instalación real cuando el usuario realiza "rpm -ivh package.rpm" será / usr / bin.

Pero recientemente, al leer algunos documentos, se sugiere que $ RPM_BUILD_ROOT sea la ubicación real que se instalará, y $ RPM_BUILD_ROOT es especificado por el usuario con la configuración de la variable de entorno $ RPM_BUILD_ROOT para que los usuarios puedan instalar el paquete en su deseo. ubicaciones De lo contrario, $ RPM_BUILD_ROOT será nulo y se instalará en la ubicación predeterminada. En el caso anterior, es / usr / bin. Por lo tanto, $ RPM_BUILD_ROOT no es solo para el proceso de empaquetado o "instalación falsa", sino que es una forma para que el usuario defina la ubicación de instalación, similar a la ubicación de carpeta seleccionada en Windows.

No sé si mi pensamiento es correcto o no. ¿Puede alguien verificarlo? Gracias por adelantado.

$RPM_BUILD_ROOT (o la macro de archivo SPEC %{buildroot} equivalente) siempre contiene el directorio en el que RPM buscará cualquier archivo para empaquetar. Los scripts RPM (por ejemplo, el script que comprime las páginas del manual) también usarán ese valor para saber dónde buscar los archivos que se acaban de instalar. Normalmente, este valor no estará vacío y contendrá una ubicación alejada de los directorios del sistema, generalmente en algún lugar debajo de /tmp o /var/tmp .

Se espera que el autor del archivo SPEC se asegure de que make install (o cualquier instalador que use el software en cuestión) coloque cualquier archivo debajo de $RPM_BUILD_ROOT , con la misma jerarquía que debe usarse cuando finalmente se instale el software. Por ejemplo, para que RPM instale ls en /bin/ls , la sección %install SPEC file debería asegurarse de que ls esté en $RPM_BUILD_ROOT/bin/ls .

También se espera que el autor del archivo SPEC use la etiqueta BuildRoot: para especificar una ubicación adecuada. Alternativamente, el sistema de compilación podría tener un archivo de configuración RPM rpmrc con una entrada adecuada. En cualquier caso, la raíz de compilación debe establecerse, de modo que:

Los usuarios normales podrán construir el paquete fuente.
Si el superusuario compilara el paquete fuente, el proceso de compilación no obstruirá ningún archivo del sistema, a menos que el superusuario instale el paquete binario resultante. Y sí, puede haber una buena razón para crear algunos paquetes como root , por ejemplo, la ejecución de la completa glibc testsuite requiere privilegios de root para algunas pruebas.

Dicho esto, RPM puede y construirá un paquete con una variable de raíz de compilación vacía. En ese caso, tanto la instalación de compilación como las ubicaciones de destino finales coincidirán. Una posible llamada a, por ejemplo, make install utilizará las ubicaciones predeterminadas, por lo tanto, eliminará los archivos del sistema bajo, por ejemplo, /usr/lib si se ejecuta con privilegios suficientes. Además, si tiene /usr/bin/* en su sección %files , felizmente arrastrará todo el contenido del directorio host /usr/bin/ build a su paquete binario.

Línea de fondo:

Nunca use una raíz de construcción vacía.
No compile paquetes como root menos que no haya absolutamente ninguna otra forma.