[…]
Preparing to unpack .../30-postgresql-common_218_all.deb ...
Leaving 'diversion of /usr/bin/pg_config to /usr/bin/pg_config.libpq-dev by postgresql-common'
Unpacking postgresql-common (218) over (217) ...
[…]
Setting up postgresql-common (218) ...
Starting PostgreSQL 13 database server: main.
[…]
postgresql-common: obsolete-conffile /etc/apt/apt.conf.d/01autoremove-postgresql
postgresql-common: obsolete-conffile /etc/postgresql-common/createcluster.conf




Looking at these files, especially the first, I’m honestly not sure
whether I want to delete them. If they are not in the binary package
any more but used to be this is probably a bug?

Dixi quod…

Looking at past changelogs, I found this:

https://salsa.debian.org/postgresql/postgresql-common/-/commit/e87adade0349a757fd0827a80cc14814487a4d30.patch

I believe this is a genuine packaging (especially upgrade) bug
introduced with that commit: the commit removed the file
/etc/apt/apt.conf.d/01autoremove-postgresql from the package
but did not unregister it as conffile.

Fixing this is probably as simple as:

• change the filename
• postinst: rm -f /etc/apt/apt.conf.d/01autoremove-postgresql on upgrade

I’ve not looked at createcluster.conf but it will, most likely, also
be caused by a similar packaging fault.

bye,
//mirabilos

Re: Thorsten Glaser

Yes, but renaming is not an option there.

I'll look into fixing this properly.

Thanks for spotting,
Christoph

Christoph Berg dixit:

Right.

Thanks!

I’ve just got adequate installed and look at its output occasionally.

bye,
//mirabilos

Re: Thorsten Glaser

I've had a closer look now. The cited commit does correctly remove the
conffile:

diff --git a/debian/postgresql-common.maintscript b/debian/postgresql-common.maintscript
new file mode 100644
index 0000000..5849b7a
--- /dev/null
+++ b/debian/postgresql-common.maintscript
@@ -0,0 +1,2 @@
+# file is now managed by pg_updateaptconfig
+rm_conffile /etc/apt/apt.conf.d/01autoremove 215~ postgresql-common

Upgrading across that version correctly removes the conffile here.

Is there anything wrong with that?

That one is indeed not handled. The conffile was converted to ucf in
version 155 in May 2014. Before I fix that (if that even makes sense
now), I'd like to understand if there is anything wrong with the
other file.

Christoph

Control: tags -1 - moreinfo

Oh, interesting. Yes, I see that in
/var/lib/dpkg/info/postgresql-common.postinst
but while /var/lib/dpkg/info/postgresql-common.conffiles
indeed does not list it any more,
/var/lib/dpkg/info/postgresql-common.list still lists it.

Checking the apt term.log archives, I have:

[…]
Preparing to unpack .../091-postgresql-common_215_all.deb ...
Leaving 'diversion of /usr/bin/pg_config to /usr/bin/pg_config.libpq-dev by postgresql-common'
Unpacking postgresql-common (215) over (214) ...
[…]
Setting up postgresql-common (215) ...
Starting PostgreSQL 12 database server: main.
[…]

So I assume this has somehow run, but perhaps silently?

I’ve got no idea, I never used dpkg-maintscripthelper yet.


The call to dpkg-maintscript-helper rm_conffile is even
in preinst of the 215 version, so it ought to have caught
that file… does dpkg-maintscript-helper log anywhere?

My best guess is that something modified that file before
the upgrade to 215, relative to… whatever dpkg-maintscript-helper
considered as “unmodified”. While this is my work laptop, not
the desktop (which I crossgraded way too much…) it’s been running
sid for many years now.


bye,
//mirabilos

Re: Thorsten Glaser

Oh, I only checked postgresql-common.conffiles in my testing today,
not postgresql-common.list. Maybe dpkg-maintscript-helper doesn't
update the .list file... Need to repeat the tests (but not tonight).

Thanks for the feedback,
Christoph

Hey.

Also found /etc/apt/apt.conf.d/01autoremove-postgresql to be an
obsolete dpkg conffile...

Though AFAIU it's still used in the package, just not longer as a
conffile "registered" to dpkg.


I think the reason why it's leftover is, that the maintainer scripts
remove:
/etc/apt/apt.conf.d/01autoremove
not:
/etc/apt/apt.conf.d/01autoremove-postgresql

/var/lib/dpkg/info# grep -i 01autoremove *postgresql*
postgresql-common.list:/etc/apt/apt.conf.d/01autoremove-postgresql
postgresql-common.postinst:dpkg-maintscript-helper rm_conffile /etc/apt/apt.conf.d/01autoremove 215~ postgresql-common -- "$@"
postgresql-common.postrm:    rm -f /etc/apt/apt.conf.d/01autoremove-postgresql
postgresql-common.postrm:dpkg-maintscript-helper rm_conffile /etc/apt/apt.conf.d/01autoremove 215~ postgresql-common -- "$@"
postgresql-common.preinst:dpkg-maintscript-helper rm_conffile /etc/apt/apt.conf.d/01autoremove 215~ postgresql-common -- "$@"
postgresql-common.prerm:dpkg-maintscript-helper rm_conffile /etc/apt/apt.conf.d/01autoremove 215~ postgresql-common -- "$@"


Of course, if you change that now,... you need to adapt the version to
"the latest version of the package whose upgrade should trigger
the operation"... so "215~" would be wrong.

Quoting the manpage:
           For example, for a conffile removed in version 2.0-1 of a package,
           prior-version should be set to 2.0-1~. This will cause the conffile
           to be removed even if the user rebuilt the previous version 1.0-1
           as 1.0-1local1. Or a package switching a path from a symlink
           (shipped in version 1.0-1) to a directory (shipped in version
           2.0-1), but only performing the actual switch in the maintainer
           scripts in version 3.0-1, should set prior-version to 3.0-1~.


Oh and things might be a bit more tricky here, because AFAIU the file
is actually still used (just not as a "registered" conffile).

It does seem to get re-created in the configure step, but that would of
course loose any user modifications.

Not really sure what should be done here...

If it had user modification, I think dpkg-maintscript-helper
rm_conffile would anyway leave the file over with some new extension...
but that's of course not a "nice" transition.

Maybe ask the dpkg people what they suggest in such situation?


Thanks,
Chris.