Bug#714725: [Pkg-postgresql-public] Bug#714725: Consider setting APT::NeverAutoRemove::postgresql-* in apt.conf
Re: Peter Eisentraut 2013-07-03 1372818582.22689.6.ca...@vanquo.pezone.net Marking only the stable version doesn't sound very reliable. If you want to guard the data, you have to do it independent of what the preferred version is. Users of apt.postgresql.org will have even more complex requirements. Nod. I was thinking about putting something like ^postgresql-.*$VERSION in the config file when a $VERSION cluster is created, and removing that once the last $VERSION cluster is removed. That would always keep the local databases running, and would also enable cleanup once they got upgraded. The place to put this would be postgresql-$VERSION.postinst, pg_createcluster, and/or the init script for creation, and pg_dropcluster and/or the initscript for removal. (Maybe another call in *.postinst.) Too much magic, too complicated? Or the right way to go? Christoph -- c...@df7cb.de | http://www.df7cb.de/ signature.asc Description: Digital signature
Bug#714725: [Pkg-postgresql-public] Bug#714725: Consider setting APT::NeverAutoRemove::postgresql-* in apt.conf
On 7/2/13 4:26 AM, Christoph Berg wrote: The question now is which package(s) should be marked as NeverAutoRemove. 1) The postgresql-x.y package of the (old)stable release 2) ^postgresql-[0-9]+-[0-9]$ 3) ^postgresql-.* 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 as well.) It should be 3), because otherwise the postgresql-contrib-x.y package will be removed and you won't be able to dump your database if it uses any data type provided in a contrib module. The same goes for things like postgresql-x.y-ip4r. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#714725: [Pkg-postgresql-public] Bug#714725: Consider setting APT::NeverAutoRemove::postgresql-* in apt.conf
Re: Peter Eisentraut 2013-07-02 51d2bd16.6020...@debian.org 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 as well.) It should be 3), because otherwise the postgresql-contrib-x.y package will be removed and you won't be able to dump your database if it uses any data type provided in a contrib module. The same goes for things like postgresql-x.y-ip4r. My thinking was that if you have any -contrib package installed, it will be marked as manually installed and won't be removed automatically anyway. Same for -ip4r and friends. Marking all postgresql-* packages for NeverAutoRemove might also be a bit overzealous, do we want to restrict this to postgresql-*$laststableversion*? Do we want to drop the NeverAutoRemove for $laststableversion once the cluster got upgraded? (This sounds like the solution could get way too complex, I want a simple thing.) Christoph -- c...@df7cb.de | http://www.df7cb.de/ signature.asc Description: Digital signature
Bug#714725: [Pkg-postgresql-public] Bug#714725: Consider setting APT::NeverAutoRemove::postgresql-* in apt.conf
On Tue, 2013-07-02 at 15:42 +0200, Christoph Berg wrote: Re: Peter Eisentraut 2013-07-02 51d2bd16.6020...@debian.org 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 as well.) It should be 3), because otherwise the postgresql-contrib-x.y package will be removed and you won't be able to dump your database if it uses any data type provided in a contrib module. The same goes for things like postgresql-x.y-ip4r. My thinking was that if you have any -contrib package installed, it will be marked as manually installed and won't be removed automatically anyway. Same for -ip4r and friends. Could be, but it's not guaranteed. Marking all postgresql-* packages for NeverAutoRemove might also be a bit overzealous, do we want to restrict this to postgresql-*$laststableversion*? Do we want to drop the NeverAutoRemove for $laststableversion once the cluster got upgraded? Marking only the stable version doesn't sound very reliable. If you want to guard the data, you have to do it independent of what the preferred version is. Users of apt.postgresql.org will have even more complex requirements. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
