I created an RPM package using CPack. The RPM package contains a C++ header file and HTML documentation generated by doxygen via cmake. The issue I am noticing is when I install the RPM package, the timestamp of created directories seem OK but the timestamps of all installed files are identical and incorrect. How do I fix this issue?
Forgot to mention that I’m using Fedora 38 which includes cmake 3.27.7.
…but the timestamps of all installed files are identical and incorrect…
What do you mean by “incorrect”? Note that the timestamps probably reflect the time you created the package. When the package is created, CMake installs things to a staging area first. I’d expect all of those staged files would have the timestamp of the install, since that’s when those files were created. To my knowledge, CMake’s install() command does not preserve time stamps of things it copies from.
I discovered that the timestamp used on the files is the %changelog timestamp in the .spec that was used. The %changelog in the .spec file looks something like this:
%changelog
- Sun Jul 4 2010 Eric Noulard eric.noulard@gmail.com - 1.0-1.fc38
Generated by CPack RPM (no Changelog file were provided)
Why is the RPM picking up the above timestamp? How do I make the timestamp reflect the RPM creation or install date?
If your project sets the CPACK_RPM_CHANGELOG_FILE variable, that will be used for the %changelog. Otherwise, it appears that cpack hard-codes the entry you quoted above. I don’t know why that particular message was chosen. Can you find formal documentation or some other authoritative reference about RPM parsing the changelog entry and using it to set the timestamps of the packaged files? That sounds like an odd thing to do.
That is exactly what I have done. I have created a changelog file and rpm picks up the timestamp from the changelog entry. Sorry, I have searched the web and reading the rpm creation documentation but have not found any specific documentation stating that file timestamps of installed files from an rpm will be based on the latest changelog entry. The latest changelog entry is expected to be the top of the changelog.