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

[Michael Biebl]

Hi,

On 20.12.2012 10:59, Andreas Beckmann wrote:
> Package: libglib2.0-0
> Version: 2.33.12+really2.32.4-3
> Severity: serious
> User: debian-qa at lists.debian.org
> Usertags: piuparts
> 
> Hi,
> 
> 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.

>     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



> 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:
> 
>     rmdir -p --ignore-fail-on-non-empty /usr/lib/x86_64-linux-gnu/gio/modules
>     rmdir -p --ignore-fail-on-non-empty /usr/lib/gio/modules
>     rmdir -p --ignore-fail-on-non-empty /usr/share/glib-2.0/schemas
> 
> Two of these directories are already owned by several packages, and the
> third should just be shipped as an empty directory by libglib2.0-0
> 

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.


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

Have you encountered any actual breakage?

Cheers,
Michael
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 900 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-gnome-maintainers/attachments/20121220/1534cba5/attachment.pgp>