Re: Bug#675613: debiandoc-sgml: Does not register itself in /etc/sgml/catalog

[Guillem Jover <guillem@debian.org>]

Hi!

On Sat, 2012-06-02 at 22:03:30 +0200, Helmut Grohne wrote:
> reassign 675613 dpkg
> affects 675613 + debiandoc-sgml docbook docbook-dsssl docbook-ebnf docbook-html-forms docbook-mathml docbook-simple docbook-slides docbook-website docbook-xml dtd-ead libcommons-validator-java python-docutils sgml-data sgml2x w3c-dtd-xhtml xml-core
> thanks

I've not checked yet exactly the exact details of this case, but I
think this is what's happening, and a way that could fix it, which
I'll be working on fixing in a moment.

> What happens is basically this:
> 
> Unpack debiandoc-sgml
>  * Now there is /etc/sgml/debiandoc-sgml.cat.dpkg-new, but no
>  /etc/sgml/debiandoc-sgml.cat.
> Activate trigger.
>  * update-catalog --update-super is run and ignores the .dpkg-new file.
>    This means that /etc/sgml/debiandoc-sgml.cat is missing from the
>    super catalog.

On unpack file triggers get activated by the explicit paths seen by
dpkg. So because the tar contains /, /etc/, /etc/sgml and
/etc/sgml/debiandoc-sgml.cat, then it will activate /, /etc/ and
/etc/sgml but not /etc/sgml/debiandoc-sgml.cat yet, because the
installation into its final place is delayed until configure time.
So update-catalog not seeing those files at that point should be
expected, but...

> Rename /etc/sgml/debiandoc-sgml.cat{.dpkg-new,}.
> Postinst debiandoc-sgml

... the problem is that whenever the conffile gets installed into
place later on, the hierarchy is not activated upwards as before, so
the trigger is not seen as the parents are not activated, and the
trigger is supposedly only watching one of the parents.

> So especially the trigger is not run again and debiandoc-sgml stays
> missing from the super catalog.
> 
> Another package affected by this handling of triggers and conffiles is
> the menu package which is interested in /etc/menu-methods
> 
> There is no obvious solution to fix this issue. I could think of the
> following options (in order of my preference):

> 1) dpkg ensures that triggers are activated after postinst is run.
>    It is not entirely clear if this behaviour is desirable. If this
>    option is not to be used the triggers.txt.gz file shipped in dpkg-dev
>    should be updated and explain issues when using triggers with
>    conffiles. In this case this bug should be reassigned to sgml-base
>    and needs to be fixed there.

So on first thought, I think the solution would be to make dpkg
activate file triggers for the parent directories on configure so that
this case is handled correctly. In fact when looking to refactor some
of the triggers code some time ago I came across the missing upwards
trigger activation, and was already considering doing exactly this, but
did not think through about the consequences, I guess that means I was
on the right track back then.

thanks,
guillem