how rpm destroyed my private key

[Jeff Johnson]

On Apr 27, 2016, at 10:12 AM, Elan Ruusamäe wrote:

> On 27.04.2016 16:55, Jeff Johnson wrote:
>> On Apr 27, 2016, at 3:13 AM, Elan Ruusamäe wrote:
>> 
>>> and it did it again!
>>> 
>> You are smart enough to identify a better solution for your problems than blaming RPM
>> for destroying your files ... again ... and again.
> 
> meh?
> 
> i described scenario that is complete for interested party to be able to reproduce and witness the destruction.
> 
> please explain how is that my problem that rpm replaced file marked as %config(noreplace) on package installation not rpm's? i'm not convinced.
> 

Sorry to be snarky ... we have gone through %config handling many many times.

In the v1 package, secret_key.php is _NOT_ in a package.
Which means:
    1) there is no way to tell if the file is modified, owned, timestamped, should be present, etc.

In the v2 package, secret_key.php is present and marked with %config(noreplace).
You are expecting rpm to rename secret_key.php before installing the v2 file to preserve
the contents because you have marked the file with
	%config(noreplace)

The %config(noreplace) handling in RPM is a decision tree based on being able to detect
whether a file is "modified". RPM will happily replace unmodified config files with altered
content even when the previous file differs. This is exactly the behavior one expects
when the newer config file has been changed, and that other executables (like daemons)
which will be restarted, are implicitly dependent on the new configuration.

RPM also goes to lengths to save "modified" %config files when they are included in packages,
as we all know.

The unmanaged version of secret_key.php that is installed does not have a record
in the rpmdb that permits detecting whether a file is "modified". So RPM replaces
(not "destroys") the file just like any archiver would do.

This is exactly the behavior one expects in the following circumstances
	1) converting an unmanaged -> managed package where "modified" can be computed
	2) replacing a misconfigured manually installed set of files with a package

Your expectations have confused the existing %config(noreplace) behavior with other
archiver behaviors. E.g. tar(1) has a number of "overwrite controi" options
	--keep-old-files
	--keep-newer-files
	--overwrite-dir
	--preserve-permissions
I doubt you would be surprised if you extracted a tar archive that "destroyed" secret_key.php,
particularly if you had forgotten to add options that might have prevented overwriting. Similarly,
if you added tar options wrongly and then found that, say, a daemon would not restart because
some config file was _NOT_ replaced as expected, I doubt that you would be surprised.

So why are you claiming RPM "destroyed" your secret_key.php file when you are misusing
	%config(noreplace)
with expectations of behavior that have never been implemented, and cannot be implemented
because there is no reference copy of metadata information needed to compute "modified", and
are in general confusing %config handling with --nooverwrite behavior?

73 de Jeff