Re: dpkg: native package in rc state prevents installation of m-a:foreign counterpart
- To: Guillem Jover <guillem@debian.org>
- Cc: 682365@bugs.debian.org, Arno Schuring <aelschuring@hotmail.com>, dpkg@packages.debian.org
- Subject: Re: dpkg: native package in rc state prevents installation of m-a:foreign counterpart
- From: Jonathan Nieder <jrnieder@gmail.com>
- Date: Sun, 22 Jul 2012 00:23:43 -0500
- Message-id: <20120722052343.GB3010@burratino>
- In-reply-to: <20120722035108.GA747@gaara.hadrons.org>
- References: <20120722043702.10897379@viper.intra.loos.site> <20120722031300.GA30833@gaara.hadrons.org> <20120722033030.GA3010@burratino> <20120722035108.GA747@gaara.hadrons.org>
Guillem Jover wrote:
> On Sat, 2012-07-21 at 22:30:30 -0500, Jonathan Nieder wrote:
>> What dpkg commands should apt run to upgrade from this state?
>
> In this particular case, apt would need to check that there's no multiple
> instances present if the new package is switching from M-A:same to
> non-M-A:same. And in that case notify the user that the package instance
> in config-files state would need to be purged.
Makes sense. Thanks for explaining.
This idea of purging one arch of a package while keeping other arches
is still new to me.
+ Most libraries' post-removal scripts run 'ldconfig' on removal and
do nothing on purge, which should work fine.
+ "libc6.postrm purge" runs db_purge. The corresponding 'owner' is
arch-qualified, making this safe.
+ Likewise for libpam0g, libpam-modules, libssl1.0.0, etc.
? "libc6-i686.postrm remove" and other optimized libc packages use
dpkg-query -l to find the version of all optimized libc packages.
The parsing does not take the colon in "Multi-Arch: same" packages
into account, so it never notices that all have been upgraded in
order to remove /etc/ld.so.nohwcap.
+ libgdk-pixbuf2.0-0.postrm is a model citizen.
+ libglib2.0-0.postrm purges some caches that are not
architecture-specific. This is probably harmless because they are
caches.
- libgphoto2-2.postrm purges .dpkg-bak files representing user
customized obsolete configuration files without checking if another
arch is staying around to take responsibility for them.
- "libgtk-2.0-0.postrm purge" wipes out /etc/gtk-2.0/*
- likewise for libgtk-3-0
- "liblockfile1.postrm remove" wipes out its documentation directory
(!)
- "libpaper1.postrm purge" removes /etc/papersize and the
corresponding ucf configuration
- "libuuid1.postrm purge" removes /var/lib/libuuid
- "libwrap0.postrm purge" removes /etc/hosts.{allow,deny}
- "libzvbi0.postrm purge" removes /etc/default/libzvbi0
Those are just the libraries I currently have installed on the machine
I am using to type this.
I guess a "general" bug is in order.
Jonathan
Reply to: