Ralf Stubner <[EMAIL PROTECTED]> wrote: >> Hm, I'm still unsure this setup will work. No matter whether we set the >> default to no or yes, won't that mean that the postinst script >> programmatically changes the file (by calling the libpaper hook, and >> libpaper will do the same), which is forbidden for conffiles? > > I think when the default is 'no', then no conffile will be edited as > long as the admin does not allow for it by answering 'yes'. Hence I > think this setup would work from the technical point of view.
etch_rc_policy.txt sounds differently: ,---- 3. Configuration files | Packages must not modify their own or other packages conffiles | programmatically. (The only correct way to modify a conffile is the | user running an editor specifically; if anything more automated is | required or useful, configuration files must _NOT_ be handled as | conffiles) `---- Running an editor on /etc/default/texpaper with the effect that now conffiles get modified programmatically by postinst scripts and paperconfig doesn't seem to comply to these requirements. On the other hand, we can't properly handle config.ps and dvipdfm/config as non-dpkg-controlled configuration files, parsing them would simply be too complex. Consequently, the only options I see are a) don't fix this bug and ignore the "system paper size" or b) separate out the papersize setting from config.ps and dvipdfm/config[1] and have a configuration file that *only* handles the papersize, and let texconfig act on that one. I don't very much like option b), since it requires extensive changes that probably don't make much sense for upstream: - patch dvips' and dvipdfm's sources to read a second configuration file - patch texconfig to read and edit a different file for paper size changes. Either only when called as texconfig-sys, or else we need to force the separation upon users who cannot really profit from it. - Document all this at all relevant places (manpage, info page, PDF/dvi documentation, README.Debian, TeX-on-Debian). Because of this, and because I don't see a problem in not supporting libpaper, I'd rather opt for wontfix. Stephen, you wrote when reporting this bug | The attached patch solves the widely-recognized problem that tetex | does not obey the system's default paper size. Except that there are a couple of old bugs in the BTS about that, what evidence do you have that this issue is actually "widely recognized" as a "problem"? And why the proper solution should be to use libpaper, instead of teaching users to use geometry.sty or hyperref.sty to include the necessary papersize specials in their documents? > I am reluctant to go for a debconf question for a different reason, > though. [...] Explaining all this would make for a quite long debconf > message which IMO is in no relation to its importance. Personally, I > find such debconf messages rather annoying. I agree. > - Should a file in /etc/default be used? Or should the paperconf hook > script directly query the the debconf database? The latter approach > might be easier. The former approach has the advantage that admins who > did not see the question due to its priority might still find that > file. At least I look into /etc/default to see what's there ... The debconf database is not a configuration cache - it may only be used to transfer information from config scripts to postinst scripts, but not by any other program. All relevant configuration *must* be somewhere in /etc, not only to suit your habits, but because it's in the Policy ;-) > - Should we offer a list of possible default paper sizes in addition to > the yes/no question? IMO that would be one of the few advantages of a > debconf question. That could be documented in /etc/default as well. Regards, Frank [1] It's easy for pdftexconfig.tex, a simple \input should be all we need. -- Dr. Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)