Please consider including a pattern to ignore /etc/.updated. The file was first noticed after upgrade to Debian trixie, generated by systemd-update-done.service. I use a /.updated line in /etc/.gitignore, but I notice the patterns in update-ignore.d/01update-ignore don't use leading slashes, perhaps the other supported VCSs don't support anchoring to repo root.
I have the file here but git log says it's only changed once since it appeared in August. Checking another machine, the file is unchanged since 2024.
It seems the file will only change if /usr's mtime is changed. It's fairly rare for a new top-level item to be added/removed to /usr, which is what changes the mtime of the directory.
This file is not configuration per se, but if the system is set up to do offline updates, it seems to me that you would want to preserve it? Also, since the offline updates do modify /etc, the change to the file that gets committed at the same time would document that offline update caused it, which seems desirable.
In my case /etc/.updated had not been committed as part of the post-upgrade commit. The file must have been created after the first reboot following upgrade. I have
AVOID_COMMIT_BEFORE_INSTALL=1set, so the following run of unattended-upgrades failed due to uncommitted /etc/.updated. The file is generated and its contents did not seem useful, hence my inclination to ignore. I use etckeeper not only as a backup of /etc, but more importantly to document the changes and in the case of /etc/.updated I had nothing to document.Right, that's what systemd-update-done.service(8) says. The comment at the top of /etc/.updated, however, says the following: "Its only purpose is to hold a timestamp of the time this directory was updated". "This directory" would seem to suggest /etc, so I'm not sure which it is. Interestingly, the file timestamp and the timestamp value inside are of 2024-02-10, while the upgrade was done on 2026-02-14.
I don't use systemd.offline-updates, so I can't say if committing /etc/.updated would be useful in that case. In the case of unattended-upgrades, it is clear from the commit message that it was the result of a u-a run.