On Thu, Apr 26, 2012 at 06:18:40PM -0400, Joey Hess wrote:
> This is why I originally recommended that the registration process be
> converted to use triggers. A [directory full] of catalogs, and a root catalog
> file automatically generated from them (which need not be a config file
> in /etc) is a much cleaner approach.
This change would be fairly intrusive, but it clearly has its
advantages. update-catalog would be updated to turn any calls containing
--super into no-ops. These configuration options are somewhat "burnt" by
the current prerm and postinst invocations and can no longer be used by
an administrator in a sane way. /etc/sgml/catalog would be regenerated
using a new update-catalog --update-super. (I don't think moving the
file elsewhere is feasible.) It would unconditionally overwrite
/etc/sgml/catalog to include /etc/sgml/*.cat. The trigger interest would
be declared in sgml-base. No trigger activation is necessary. The
generated /etc/sgml/catalog would explain that to remove a catalog an
administrator should call update-catalog --disable $package. This would
mv /etc/sgml/$package.cat{,.disabled} and --update-super. Similarly
--enable $package would revert this change. These file moves persist
during upgrades, because removed conffiles are not readded. Does this
method have any obvious problems? I can write a patch.
Helmut
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
