On 08.08.2025 00:51, Stoiko Ivanov wrote:
On Sun, 16 Mar 2025 07:44:42 +0300 Michael Tokarev <[email protected]> wrote:
11.03.2025 14:54, Cornelius Hoffmann wrote:
Package: postfix
Version: 3.10.1-1
Severity: important
(BTW, using cp(1) here is wrong due to a different reason, - the -u
option, - once we've a file in chroot which is more recent, reverting
back to old version - eg, downgrading a package - doesn't work anymore).
We ran into a few spurious warnings about files differing while upgrading
a few systems from bookworm to trixie.
One case was /etc/services having the mtime from packaging, while
/var/spool/postfix/etc/services having one from today (despite containing
the contents from bookworm). Another one is from systems where
/etc/localtime is set by a script right after postfix check is called
(mtimes/ctimes/btimes are identical, despite /etc/localtime being "newer").
I created a merge request in salsa to drop the -u option:
https://salsa.debian.org/postfix-team/postfix-dev/-/merge_requests/48
and think that dropping `-u` here makes sense.
Hi!
I don't really want to drop `-u' from here. The same problem exists
when updating ssl certs for example, - and re-creating all the files
every time seems like a wrong idea.
See also #1110704 for exactly the same issue.
Instead, I created a poor-man cp(1) replacement in perl, which addresses
3rd issue - it does copy+rename instead of truncate+copy, so that the
files are created atomically. Another tool which does it is rsync,
but I don't want to depend on rsync here.
I felt such tool was needed, but I was lazy to write one.
I plan to perform an update to postfix package in the next trixie point
release.
Thanks,
/mjt
