Bug#1110696: libglib2.0-0t64: Purging libglib2.0-0:i386 removed gschemas.compiled

[Simon McVittie]

On Tue, 12 Aug 2025 at 10:35:34 +0800, Tianyu Chen wrote:
>Actually I don't think I've purged libglib2.0-0:amd64 when testing
>bookworm->trixie upgrading.

Hmm, in your log, I see the status of libglib2.0-0:amd64 change from 
config-files to not-installed, but I don't see an explicit purge 
operation:

2025-08-10 00:08:42 purge php8.1-common:amd64 8.1.12-1+b1 <none>
2025-08-10 00:08:42 status config-files php8.1-common:amd64 8.1.12-1+b1
2025-08-10 00:08:46 status not-installed php8.1-common:amd64 <none>
2025-08-10 00:08:47 status config-files libglib2.0-0:amd64 2.78.4-1
2025-08-10 00:08:47 status not-installed libglib2.0-0:amd64 <none>
2025-08-10 00:08:47 purge libglib2.0-0:i386 2.78.0-2 <none>
2025-08-10 00:08:47 status config-files libglib2.0-0:i386 2.78.0-2
2025-08-10 00:08:47 status not-installed libglib2.0-0:i386 <none>
2025-08-10 00:08:47 purge libpython3.9-minimal:amd64 3.9.13-1 <none>

and there is no trace in apt's terminal output:

Purging configuration files for php8.1-common (8.1.12-1+b1) ...
dpkg: warning: while removing php8.1-common, directory '/etc/php/8.1/mods-available' not empty so not removed
Purging configuration files for libglib2.0-0:i386 (2.78.0-2) ...
Purging configuration files for libpython3.9-minimal:amd64 (3.9.13-1) ...

I'm not sure how that can happen.

Could dpkg have noticed that the postrm had been deleted, and concluded 
that there was nothing left to purge, as a side-effect of doing other 
filesystem operations? (e.g. while it was purging php8.1-common)

     smcv