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 necessary. 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. Helmut -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
