[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Policy conformant conffile handling...



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


Reply to: