Bug#682365: dpkg: native package in rc state prevents installation of m-a:foreign counterpart
Hi!
On Sun, 2012-07-22 at 00:23:43 -0500, Jonathan Nieder wrote:
> 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.
No problem. :)
> This idea of purging one arch of a package while keeping other arches
> is still new to me.
Well that could happen still due to explicit user request, so it's
something that needs to work correctly from the maintainer script
point of view anyway, and the consequences of this are due to the
file ref-counting, which in the maintainer scripts case will need
to be handled semi-manually for files not tracked by dpkg.
> + "libc6.postrm purge" runs db_purge. The corresponding 'owner' is
> arch-qualified, making this safe.
>
> + Likewise for libpam0g, libpam-modules, libssl1.0.0, etc.
That's been one of the reasons to always arch-qualify package names
for M-A:same packages, yes.
> ? "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.
This might need to be checked, I pointed to watch for this kind of
issue in my mail to d-d-a, though.
> + libglib2.0-0.postrm purges some caches that are not
> architecture-specific. This is probably harmless because they are
> caches.
It's still wasteful and unneeded, should get fixed, but not too
serious.
> - 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
Yeah, all the above should get bugs reports.
> 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.
I'm not sure that will help much. Instead I guess a mail to d-d might be
bettet given that people seems to have not realized the consequences of
ref-counting files. And then individual bugs being filed.
thanks,
guillem
Reply to: