Bug#696389: libglib2.0-0: harmful postrm actions for M-A: same package: rm -f /usr/lib/.../modules/giomodule.cache /usr/share/glib-2.0/schemas/gschemas.compiled

[Andreas Beckmann]

On 2012-12-20 14:38, Michael Biebl wrote:
> Hi,
> 
> On 20.12.2012 10:59, Andreas Beckmann wrote:
>> libglib2.0-0.postrm does some cleanup that is potentially harmful in a
>> multiarch setup. Just think about libglib2.0-0:someforeignarch being
>> removed while libglib2.0-0:native is kept installed:
>>
>>     rm -f /usr/lib/x86_64-linux-gnu/gio/modules/giomodule.cache
> 
> This one is not critical.
> 
>>     rm -f /usr/lib/gio/modules/giomodule.cache
> 
> This one is a fallback only. There aren't any packages in the archive
> anymore shipping gio modules in /usr/lib/gio/modules. So while this
> might be theoretical issue, it shouldn't be in practice.
> That said, since it is created on the native arch only anyway (see
> postinst) maybe we should also only rm it on the native arch?
> 
> An alternative could be, to ship the /usr/lib/gio/modules/ directory in
> the libglib2.0 package, so the trigger is activated upon removal.
> 
> But as said, I don't think this directory/cache file will produce issues
> in practice.

I have no idea what creates and uses these files - but since they
exist(ed) for a reason I see the potential the incorrect removal may
break things and we better double check before the release :-)

>>     rm -f /usr/share/glib-2.0/schemas/gschemas.compiled
> 
> We do have a triggers for /usr/share/glib-2.0/schemas, so I think they
> should be activated after libglib2.0-0:$arch has been removed. A quick
> test confirms that:
> 
> # ls -la /usr/share/glib-2.0/schema
> -rw-r--r-- 1 root root 332 Dec 20 13:27
> /usr/share/glib-2.0/schemas/gschemas.compiled
> 
> # apt-get remove libglib2.0-0:i386
> ...
> Removing libglib2.0-0:i386 ...
> Processing triggers for libglib2.0-0:amd64 ...
> 
> # ls -la /usr/share/glib-2.0/schema
> -rw-r--r-- 1 root root 332 Dec 20 13:28
> /usr/share/glib-2.0/schemas/gschemas.compiled

and now let's purge the package, this runs the removal code again and
does not activate a trigger.

(that's the piuparts order of doing purge tests: remove $package, remove
$dependecies, purge $depdencies, purge $package - this should uncover
more cases where postrm purge uses something non-essential)

gschemas.compiled will be missing until something activates and runs the
trigger again.

>> The latter two should only be done when removing the last instance of
>> libglib2.0-0 ... or some trigger should be actived that may
>> update/recreate these caches ...

>> Furthermore the directory removal is not needed as well, because this
>> should be handled dpkg and its reference counting:
...
> Since the cache files are cleaned up in postrm, the directories won't be
> cleaned up automatically by dpkg so we need those rmdir calls.

I expect this to be fixed in dpkg for jessie. There is a patch already,
but it came a bit late for getting into wheezy. I verified that this
works well on a full piuparts run on sid with the patched dpkg.

>From a piuparts point of view I'd prefer to stop working around this in
the affected packages - you can not be sure whether a rmdir call would
be correct or some other installed package has some interest on the
empty directory (and I'll happily add these directories to piuparts'
ignore list for now s.t. they don't show up as leftovers). And wrong
rmdir's may be more problematic in the multiarch age.

> In summary: I don't see any actual issue here, at least not one which
> would justify the severity.

I see the potential for things getting broken in very subtle ways ...

> Have you encountered any actual breakage?

... but I don't know anything about glib/schemas to actually check for
broken things.

So this should be fixed or someone should prove that it is harmless if
some files/directories "disappear" from libglib2.0-0.

There was a similar issue in libuuid* (Priority: required) where some
directory in /var/lib was disappearing after purging libuuid*:foreign
After that was fixed recently I started looking for more candidates this
morning ...

Andreas