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 biebl at debian.org
Thu Dec 20 21:44:02 UTC 2012


On 20.12.2012 19:12, Andreas Beckmann wrote:
> On 2012-12-20 14:38, Michael Biebl wrote:
>> 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/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?

..

>>>     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

..

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

..

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

yeah, looks like multiarch in combination with trigger is a tricky
business :-/

>>> 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 ...

I think the attached patch should address both issues:
a/ It only removes the /usr/lib/gio/modules/giomodule.cache file on the
native arch
b/ Explicitly triggers a file trigger after removing the schema cache
file. This means there can be a time frame where the cache file is not
available. But I couldn't come up with a nicer solution.


>>> 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.

Speaking of reference counting, a helper like dpkg-rm could be useful in
cases like this, where a file should only be removed when a given
package has been removed for *all* architectures.

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: glib-cache-files.patch
Type: text/x-patch
Size: 901 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-gnome-maintainers/attachments/20121220/a7a9a99c/attachment-0001.bin>
-------------- 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/a7a9a99c/attachment-0001.pgp>


More information about the pkg-gnome-maintainers mailing list