search

mojohaus / rpm-maven-plugin

http://www.mojohaus.org/rpm-maven-plugin/
Other
56 stars 48 forks source link

2.1.4: mapping configuration=true broken #19

Open jouvin opened 8 years ago

jouvin commented 8 years ago

It seems that in the last version of the plugin (2.1-alpha1) configuration=true for mapping definition is not properly handled anymore. In the past, it was setting the noreplace flag for the file in the RPM but this is no longer the case. As a result, a RPM generated with this version of the plugin is overwriting local modifications with the vanilla file provided by the RPM.

jouvin commented 8 years ago

I realize that this is an already old version of the plugin... I'm trying to figure out why we don't use the last one...

jouvin commented 8 years ago

Problem in the context of the project where it was identified has been understood. There was an inadvertent change to the pom file where the value was changed from noreplace to true.

I remains that the true value, according to the documentation should have done what is appropriate, thus the noreplace flag should have been set in the RPM, isn't it?

jouvin commented 8 years ago

I upgraded to the last version of the rpm-maven-plugin and the behaviour remains the same: if using configuration=true the noreplace flag is not set in the RPM. For me, this is inconsistent with the documentation that says: "If present or populated with the value true, the files in this mapping are marked as configuration files. These files get special treatment during package installation to ensure that local changes to the configuration are not lost."

bokken commented 8 years ago

RPM has different behavior for configuration files. The first option (which is configuration = true), will keep a copy of the existing file with a .rpmold extension during an upgrade when there had been changes to the existing file. The second option is noreplace, which will deliver the new file with .rpmnew during an upgrade when there have been changes to the existing file.

Both of these are "special treatment" during package installation. It is a question of whether you want to give priority to keeping the local changes in place (noreplace) or just having the ability to easily determine what was previously in place (true).

jouvin commented 8 years ago

Thanks for the answer and the clarification. Makes sense! But it may be worth a clarification in the doc as the sentence mentionned could led to think that this is the noreplace behaviour (local changes are not lost). May be it would be clearer to say that the local changes are saved before installing the new file and to indicate that if you want to preserve the local file you should use noreplace. I let you close the issue.