Bug#706110: libgnome{, vfs}2-common: fails to upgrade from squeeze: prerm failure: gconf-schemas: not found

[Andreas Beckmann]

On 2013-04-27 00:56, Michael Biebl wrote:
> Am 27.04.2013 00:50, schrieb Michael Biebl:
>> Am 26.04.2013 19:17, schrieb Josselin Mouette:
>>> Le vendredi 26 avril 2013 à 18:54 +0200, Josselin Mouette a écrit : 
>>>> I think we only need to fix the packages:
>>>> * that still have a dh_gconf prerm snippet in squeeze
>>>> * AND that don’t have a prerm anymore in wheezy (or that haven’t been

> That all said, I do not particularly like this workaround/hack and I
> would very much prefer if the situation could be avoided during the
> upgrade where /usr/bin/python is a dangling symlink.

I haven't looked at the packages at all, I don't know what dh_gconf
does, I don't know anything about gnomish packaging.
What I understood from the discussion is the following:

* in squeeze, dh_gconf generated maintainer script snippets
* in wheezy this no longer happens, perhaps the gconf things were
reorganized completely

* OK, now I looked at squeeze's libgnome2-common.prerm and see
# Automatically added by dh_gconf
if [ "$1" = remove ] || [ "$1" = upgrade ]; then
        gconf-schemas --unregister $LONG_LIST_OF_SCHEMA_FILES
fi
# End automatically added section

* What happens if that is *not* done during upgrades? Is there perhaps
something that would magically fix this up in wheezy? At least
/var/lib/dpkg/info/gconf2.triggers has "interest /usr/share/gconf/schemas"

If skipping the old gconf-schemas --unregister call is not problematic
because an equivalent action will be done by trigger processing (and no
stale schemas will stay registered), adding the empty dummy prerm should
be a safe solution. And we should do it at least for the two packages
that have shown to produce the problem so far.

Of course we would like to understand what happens to make python
dangling ... but given the tight timeframe we probably can't analyze/fix
that in depth. But we might work around this, especially if we are sure
not to hide any problems by doing this - i.e. if the gconf-schemas
--unregister call is actually superfluous.


Andreas