Hi Daniel, On Mon, Dec 05, 2011 at 12:05:26AM +0100, Daniel Leidert wrote: > My thoughts on this are pretty easy. There are IMO three mechanisms to > use: > > (1) Register the catalog, if it exists (and unregister any registered > catalog, if it doesn't exist anymore). So users can remove the package > catalog file. > > (2) Register the catalog only during installation, but not during > upgrade. Usually we only add a catalog reference to the super > catalog.
This is what I proposed. It can be done today with a simple change to debhelper and no changes to sgml-base. > (3) Catalog files should be written at build time not during > installation. Instead of creating /etc/sgml/package.cat during > installation, this should be created during package build. So the user > can edit /etc/sgml/package.cat and /etc/sgml/catalog and we preserve > these changes. Initially I thought about this as well. The problem with this is that currently /etc/sgml/package.cat is not owned by any package. So by switching a package to this model, each installation would prompt the user for those files. > If the user now changes /etc/sgml/package.cat and we need to ship an > updated file, he should usually be asked, if he wishes to update the > file during installation. > > IMO we don't need to check, what has been "disabled" or not. Or does > this have any advantages IYO? It works without asking the user questions during upgrade. This applies both to a transitioning period and to the long term when a package.cat changes. I don't really care whether the user is asked on package upgrades after he changes those files. But installations where no user changed those files should definitely not ask the user. So I propose that either you come up with a method to cleanly take over ownership of those configuration files or we use my approach. In any case this bug should be fixed some way or another. Helmut -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
