[xml/sgml-pkgs] Bug#477751: tackling this bug

[Helmut Grohne]

Hi Joey,

thanks for your response.

On Sat, Jan 07, 2012 at 01:01:56PM -0400, Joey Hess wrote:
> Helmut Grohne wrote:
> >  * preinst will do the tricky transition part. If it is called during an
> >    upgrade and /etc/sgml/$package.cat is not owned by any package (this
> >    is currently the case), then it fixes up the installation. The old
> >    prerm will have the package catalog removed from the root catalog, so
> >    it is readded here. The old postinst would recreate
> >    /etc/sgml/$package.cat. This file is removed during preinst. The
> >    advantage of this approach is that the conffile can be installed
> >    without asking the user. The disadvantage of this approach is that
> >    we are overwriting user changes one more time.
> 
> I don't think it's appropriate to put "tricky transition" code into
> debhelper autoscripts, from where it is exploded out to lots of
> packages. If it's tricky, it's going to break, and it needs to be in a
> centralized location so the breakage can be fixed with one upload.

I agree that the complexity should not reside in debhelper templates.
However that is already the case. The entire code that is responsible
for #88010 already is contained in debhelper. It is debhelper's prerm
that removes the package catalog from the root catalog. And it is
debhelper's postinst that removes the package catalog file. Those are
two removals shipped in current debhelper and they are causing the harm.
One of those removals is done using /bin/rm (out of scope of sgml-base)
and the other removal is a call to update-catalog --quiet --remove
--super /etc/sgml/$package.cat. Turning this into a no-op is error prone
on its own as it might legitimately be invoked that way from a user.

Please observe how my debdiff reduces this complexity. By generating the
package catalog at build time the code that modifies the package catalog
at installation time is removed altogether. All that remains are two
calls to update-catalog in postinst and prerm to modify the root
catalog. The preinst and postrm contents are only needed for the
transition period to fix old stuff.

> Also, it's quite likely that other packages also use update-catalog,
> without using dh_installcatalogs. So this should be fixed in
> update-catalog.

Unless those other packages use the same snippets as debhelper they are
not affected. If they do, those packages need to be fixed separately,
but this issue cannot be solved by a change to update-catalog.

> >  There is a debhelper.debdiff attached which implements the above
> > description. I have rebuild xml-core using this patched debhelper and
> > tried to upgrade and reinstall xml-core. However downgrading xml-core
> > and upgrading it again results in a broken installation. Even when
> > downgrading a package a conffile stays to be a conffile, so the preinst
> > hook is only executed during the first upgrade. After the second upgrade
> > the /etc/sgml/$package.cat is left untouched (being a conffile) and
> > missing from /etc/sgml/catalog.
> 
> It's not clear to me if this is a serious problem with this approach or
> not. I will let the maintainer of update-catalog deside when
> implementing their solution.

If you can come up with a better approach to detect an old debhelper
template, I can adapt the patch. For instance I could craft a regular
expression for grepping $(dpkg-query --control-path $package postinst).

I would expect a number of packages to break when you try to downgrade
them. Also note that downgrading packages is not officially supported
(especially when downgrading towards a broken package).

As far as I can see sgml-base is unmaintained. It received its last
maintainer upload in 2004, so it seems pointless to wait for the
maintainer.

Helmut