Hi, I had thought that I had understood it. But somehow I'm again running into problems when it comes to manipulating configuration files with maintainer scripts.
TeXLive contains many binaries that change output depending on the papersize used. Each of them has a configuration file which - among other settings - defines the default papersize (it can and should be overwritten in the TeX input file). Now I want to integrate this with libpaper: The default papersize for each binary should be the system paper as given by libpaper. TeXLive upstream even ships a configuration program, texconfig, that allows to set the papersize for all binaries to the same value. However, and here's the policy-related problem: Of course the admin might have changed the default paper for one particular binary manually. What should I do in this case? Here are some options I considered: - let libpaper's setting overwrite everything: Probably not intended; not policy-compliant - patch the upstream texconfig tool to check for a string like % Debian-manually-changed-configuration=NO and only propagate the libpaper setting if this is unchanged. This is, IMO, a) ugly b) error prone, since people tend to overlook they need to make two changes - add some complex script logic that tries to detect whether a configuration file has been changed by checking * whether the setting is still as shipped, or * still the same as set by the last invocation of texconfig, to be recorded somehow if one of the questions is answered "no", don't change anything. At the moment, I think the last option seems to be the only really policy-compliant way. On the other hand, it is ugly hacking, requires a rather complicated patch to texconfig that might be hard to maintain, and if we ever were to change the default "as shipped" (e.g. because we overlook an upstream change), the patch would get even messier. Are there any other options? Currently, the configuration files in question are all conffiles; we'd have to change that, too, I guess. I have not followed this field in the last years; I guess ucf is still the method of choice if a maintainer script needs to do a specific manipulation in an otherwise not-generated configuration file? TIA, Frank -- Dr. Frank Küster Debian Developer (TeXLive) VCD Aschaffenburg-Miltenberg, ADFC Miltenberg B90/Grüne KV Miltenberg -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org