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
_______________________________________________
pld-devel-en mailing list
pld-devel-en@lists.pld-linux.org
http://lists.pld-linux.org/mailman/listinfo/pld-devel-en
