Bug#402994: use new libpaper hook to track system paper size
On Sun, Dec 17, 2006 at 14:43 +0100, Frank Küster wrote:
>
> 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)
> `----
Hmm, this is much more strict than I thought. It does make sense,
though, since if the admin did not change the file directly, (s)he won't
be able to evaluate the diff presented during an upgrade. Actually this
makes shipping a tool like texconfig rather dubious. If we ship files
like config.ps as configfiles, and the admin runs 'texconfig-sys', this
configfiles will be changed without the admin actually knowing this.
> 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.
This rules out more or less anything that me discussed so far. :-( What
possibilities exist to handle configuration files not as conffiles?
> 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.
texconfig can do more than change the default paper size, so it has to
act on several files. But that would mean that these configuration files
for paper sizes are not conffiles. What would we gain here? Especially
given that the paper size handling in config.ps is rather complicated.
> I don't very much like option b), since it requires extensive changes
> that probably don't make much sense for upstream:
[...]
ACK
> > - 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.
I meant not only a list but a 'selectable list'. Something like this:
,----
| default papersize?
| [ ] use libpapaer
| [ ] a4
| [ ] letter
| ...
`----
Or like this:
,----
| Use libpaper?
| [ ] yes
| [ ] no
`----
If 'no':
,----
| default papersize?
| [ ] a4
| [ ] letter
| ...
`----
Hence the admin would be able to choose the default paper size during
installation instead of having it set from libpaper's value. But I guess
that isn't allowed by policy either without extensive changes to the
programs.
cheerio
ralf
Reply to: