[Pkg-postgresql-public] Bug#714725: Consider setting APT::NeverAutoRemove::"postgresql-*" in apt.conf
myon at debian.org
Tue Jul 2 08:26:28 UTC 2013
I've twice seen people on #postgresql who were upgrading from squeeze
to wheezy and ended up with postgresql-8.4 removed and postgresql-9.1
installed, the existing 8.4 cluster being inaccessible. What happened
there is that they have "postgresql" installed, and apt(itude)'s
autoremove feature cleaned the 8.4 package because postgresql is now
Technically there is nothing wrong; they should just have paid more
attention to what packages the package manager is going to autoremove,
and noticed that the 8.4 packages should not yet be removed.
However, we should think about making this more user-friendly. Apt
supports exclude lists for autoremoval, the default config already
uses this for kernels and related packages (and metapackages), see
/etc/apt/apt.conf.d/01autoremove. Ubuntu even generates a list of
kernel packages to keep automatically from the kernel postinst in
The question now is which package(s) should be marked as
1) The postgresql-x.y package of the (old)stable release
2) is probably equivalent to 1), as there's only one version in
stable, and also easier to maintain, because we don't need to deal
with changing the file, and partial upgrades.
3) would be needed if we decide that we also need to care about
extension modules that should not be removed on dist-upgrade. (Though
I tend to think these would usually be manually installed. But we
might have the same metapackage-with-changing-dependency problem there
The place to put this would be a static file in the postgresql
package, or a file maintained by postgresql's postinst.
Comments? I'd tend to go for 2) because it's easy and likely to catch
most of the problems.
cb at df7cb.de | http://www.df7cb.de/
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 836 bytes
Desc: Digital signature
More information about the Pkg-postgresql-public