Hi! On Tue, 2025-08-12 at 11:21:10 +0100, Simon McVittie wrote: > 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) dpkg will automatically turn a remove into a purge if the package has no conffile and no postrm: https://git.dpkg.org/cgit/dpkg/dpkg.git/tree/src/main/remove.c#n639 But from the attached log files in the bug report, I see there was an explicit purge request for libglib2.0-0:i386. (Probably I'm missing some context here from the previous mails or bug report.) Regards, Guillem
