¿El archivo .rpmnew no se creó al actualizar el paquete?

¿El archivo .rpmnew no se creó al actualizar el paquete?

Actualmente estoy probando la instalación de un RPM con un archivo de configuración usando la config(noreplace)directiva.

segúnusando config(noreplace)mi archivo de especificaciones marca un solo archivo como archivo de configuración:

%config(noreplace) /opt/lm/dest/conf/db.xml

Hice una modificación en el disco del archivo para la versión 1 y procedí a actualizar a la versión 2. Esperaba que la salida detallada (al usar -Uvh) indicara que había creado un db.xml.rpmnewarchivo que no fue así, sin embargo, las modificaciones en el disco que hice están intactos.

¿Alguien sabe por qué este podría ser el caso?

Alguna información general: estoy usando el mismo archivo tar para crear las versiones 1 y 2, lo que no debería hacer una diferencia, pero pensé en mencionarlo de todos modos.

EDITAR 1:

En caso de que no estuviera claro, el db.xml.rpmnewarchivo no se creó.

Respuesta1

Lo que observa es el comportamiento esperado. A.rpmnewEl paquete solo se crea cuando se cumplen las dos condiciones siguientes:

  1. El archivo de configuración predeterminado en el nuevo paquete RPM es diferente del archivo de configuración que se incluyó originalmente en la versión actual/anterior del paquete RPM. (El responsable del mantenimiento del paquete ha realizado cambios en los valores predeterminados).
  2. el archivo de configuración real en el disco ha cambiado del valor predeterminado que se incluía en la versión actual/anterior del paquete. (El administrador ha realizado cambios con respecto a los valores predeterminados).

Según el registro de cambios:

commit e64bf5b93ab689e6031fce4489e4ae38ebaebef1
Autor: Panu Matilainen
Fecha: martes 28 de agosto 09:04:09 2007 +0300

Evite .rpmnew cuando el archivo no haya cambiado en el paquete (rhbz#194246)

El comportamiento actual de %config(noreplace) crea un archivo .rpmnewfile si el tipo del archivo actual se ha cambiado al que estaba instalado originalmente.

El parche cambia este comportamiento de modo que cuando lo antiguo y lo nuevo (en la base de datos y en el paquete) sean idénticos -> no cambien, la función devuelve FA_SKIP -> no bloqueará nada, simplemente omitirá la instalación del archivo del paquete. Este parche también maneja el caso opuesto cuando los paquetes nuevos y antiguos contienen %configenlaces simbólicos y tenemos un archivo normal en el disco.

Patch from Tomas Mraz.

información relacionada