Bug#402994: use new libpaper hook to track system paper size
Ralf Stubner <ralf.stubner@web.de> 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)
Reply to: