La sección %files identifica los archivos y directorios agregados por el paquete, y así entonces, cuáles archivos y directorios son propiedad del paquete. La propiedad es importante, cuando usted tipea "rpm -qif bla" usted podrá visualizar a quién pertenece bla .
Fundamentos %files¶
La sección %files normalmente comienza con una línea %defattr que define los permisos de los archivos por omisión. El formato de la línea es %defattr(<permisos de achivo>, <usuario>, <grupo>, <permisos de directorio>), esto significa que puede especificar los permisos que aplican a los archivos y directorios en la sección %files. El cuarto parámetro es a veces omitido. Usualmente se usa %defattr(-,root,root,-), donde "-" significa "use los permisos por omisión".
Esta línea es seguida por nombres o patrones de directorios o archivos que serán instalados y propiedad de este paquete. Usted debería usar macros para los nombres de directorio, e.g., use %{_bindir}/miarchivo en vez de /usr/bin/miarchivo, y %{_sbindir}/killaccount en vez de /usr/sbin/killaccount. Si un nombre o patrón comienza con"/" cuando se expande, entonces se presume que ha sido copiado en %{buildroot} seguido de dicho patrón, cuando se instale en sistema final, será copiado en ese nombre sin el prefijo buildroot. Si usted no precede con "/", entonces se presume estar en el directorio actual (e.g., dentro del directorio de construcción) - esto se usa para archivos de "documentación". Asi que si su paquete sólo instala /usr/bin/micomando, entonces su sección %files podría ser simplemente:
%files
%defattr(-,root,root,-)
%{_sbindir}/mycommand
Cualquier archivo o directorio identificado en la sección %files es propiedad del paquete que lo define. Usted debería asegurarse que declare la propiedad para cada nuevo archivo o directorio que el paquete cree. Puede utilizar wildcards (*) que abarquen a un grupo de archivos, esto hace que el paquete sea menos sensible a los cambios. Por ejemplo, usted puede declarar que todos los archivos que fuesen copiados en en %{buildroot}/usr/bin fuesen propiedad de este paquete declarando:
%{_bindir}/*
Note que "%{_bindir}/*" no reclama que este paquete sea dueño del directorio /usr/bin - reclama que todos los archivos que fueron instalados dentro del ''build root'' /usr/bin son propiedad del paquete. Si usted lista un directorio in la sección files, entonces usted está reclamando que este paquete es dueño de ese directorio y todos sus archivos en él, recursivamente (todos hacia abajo ) si están presentes en la raíz de construcción. No liste los directorios "/usr/bin" o "{_bindir}" directamente en sus lista files porque ello reclamaría la propiedad de /usr/bin y todo dentro de él. El reclamar la propiedad de "{_bindir}/*" está bien, ya que sólo reclama la propiedad de los subdirectorio y archivos que usted coloque bajo /{_bindir}. Si crea un subdirectorio tal como /{name}, (/usr/share/NAME), usted debería incluir el directorio en la lista %files:
%{_datadir}/%{name}/
Usualmente es más fácil utilizar wildcards para los nombres de archivo, y también es mejor que copiar con cambios aguas arriba. La documentación antigua RPM típicamente muestra largos listados bajo %files con nombres individuales, tal como /usr/bin/programa1 seguido de /usr/bin/programa2. Debido a la forma como Fedora usar buildroots ahora, esto ya no es necesario.
Es un eror si ningún archivo hace coincidencia con el wildcard en la línea, así que sólo liste los directorios que de hecho importan. Tampoco puede identificar el mismo archivo o directorio más de una vez. Finalmente, es un error tener algo en el buildroot y no listado bajo %files, el punto de copiar algo en el buildrott es porque usted pretende tenerlo instalado en el sistema final. Si usted no pretende eso, remueva dichos archivos durante el proceso %install.
También es posible excluir archivos de la coincidencia anterior utilizando el glob %exclude. Esto puede ser útil para incluir "casi todo" los archivos que hacen coincidencia con glob diferente. Sin embargo, note que, como cualquier otro glob, incluso el glob %exclude fallará si no hace coincidencia con algo. Esto puede parecer contraintuitivo ya que el objetivo es esencialmente asegurarse de que cierto archivo NO exté ahí, así que esta regla es particularmente importante que la recuerde.
Prefjos %files¶
Usted puede necesitar agregar uno o más prefijos a la entrada %files (si es más de una, use espacio en blanco para separarlos).
Típicamente hay una entrada "%doc" con una lista de archivos de documentación que no fueron copiados en el buildroot, usualmente al menos hay un archivo README y un archivo LICENSE. Usted debe incluir un archivo para la licencia., si es que hay uno. Usted puede prefijar algunos de éstos con attr(mode, user, group) para definir los permisos del archivo, el usuario y el grupo. Uste no necesita reclamar la propiedad del directorio /usr/share/doc/{name} , ello es automático. Cualquier entrada %doc no debe afectar la aplicación en tiempo de ejecución (si está en %doc, el programa debe ejecutarse apropiadamente si no están presentes).
Si usted guarda archivos de configuración (bajo /etc - no los coloque bajo /usr), usted debería prefijarlos con %config(noreplace) a menos que esta versión de programa use un formato de configuración no compatible hacia atrás (en cuyo caso, prefíjelos con %config).
Prefijar las entradas %files con "%attr(mode, user, group)" le permite establecer los permisos para archivos particulares, e.g., "%attr(0644, root, root)". Un "-" significa "usa los valores por omisión".
Si un archivo está en un lenguaje natural particular, use %lang para anotarlo. E.G.:
%lang(de) %{_datadir}/locale/de/LC_MESSAGES/tcsh*
Algunas documentaciones dicen que %license y %readme son prefijos válidos, no lo son, en Fedora. Use en sustitución %doc.
%files y el Filesystem Hierarchy Standard (FHS)¶
Usted debería seguir el estandar Filesystem Hierarchy Standar, i.e., los ejecutable de aplicaciones ordinarias van en /usr/bin, los archivos de configuración global en /etc, las librerías ordinarias en /usr/lib, y así, con una excepción, los ejecutables que no deberían normalmente ser ejecutados por usuarios o administradores, deberían ir al subdirectorio /usr/libexec, usualmente usted se referirá al directorio necesario como "%{_libexecdir}/%{name}".
Usted no debería instalar archivos bajo /usr/local, allí es donde van los archivos no empaquetados. Típicamente existirá un atributo "prefijo" que le permitirá definir el prefijo para que sea "/usr" en vez de "/usr/local".
Desafortunadamente las rutinas "normales" de instalación de muchos programas no siguen el FHS. En particular muchos programas colocarán la librerías dependientes de la arquitectura bajo /usr/lib, en vez de bajo /usr/share como lo manda el FHS. El FHS /usr/lib section indica que /usr/lib para datos "dependientes" de la arquitecturar (e.g., archivos ELF como los archivos .so), mientras que /usr/share es para datos "independientes" de la arquitectura. De esa forma, los sistemas con diferentes CPUs pueden compartir /usr/share. Hay muchas excepciones a esta regla en Fedora (e.g., Python y Perl), pero Fedora aplica esta regla lo más estrictamente que otras distribuciones. Note, por ejemplo, que rpmlint se quejará si usted coloca cualquier otra cosa que archivos ELF en /usr/lib.
Ejemplo %files¶
Aqui sigue un ejemplo simple de una sección %files:
%files
%defattr(-,root,root,-)
%doc README LICENSE
%{_bindir}/*
%{_sbindir}/*
%{_datadir}/%{name}/