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

Helmut Grohne helmut at subdivi.de
Sat Jan 7 21:25:18 UTC 2012

Hi Joey,

On Sat, Jan 07, 2012 at 02:53:46PM -0400, Joey Hess wrote:
> But update-catalog can get new switches that handle the transition, and
> debhelper can update the code to use them.

Ok. Let's evaulate what could be changed about update-catalog.
1) package catalog.
   As per Daniel's request the package catalogs are now created at build
   time, so update-catalog no longer touches them. The only place we
   still touch the package catalog is to remove it (being an unowned
   file in /etc) to transition to a proper configfile. So we would add
   some update-catalog --transition-catalog to the debhelper preinst. It
   would have do the magic to detect whether this transition is actually
2) root catalog.
   The package catalog is currently removed and readded to the root
   catalog during every upgrade. This is to change, but the next upgrade
   will still do the removal. So the --transition-catalog would do this
   as well.

This --transition-catalog would do harm to the system when invoked by an
administrator since it relies on the broken behaviour of debhelper's
prerm and the creation of the conffile by the package upgrade.

Essentially the transitional code that I put into preinst would be moved
to update-catalog. I honestly do not see the value in this. In fact it
the complexity is even larger since we now have to depend on a newer
version of sgml-base and if we really need to apply further fixes we
need to change two packages now. Not mentioning the combinatorial
explosion of version combinations (of debhelper and sgml-base). Another
argument against this move is that it makes removing the transitional
code much harder.


More information about the debian-xml-sgml-pkgs mailing list