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

Bug#402994: use new libpaper hook to track system paper size



Julian Gilbey <jdg@polya.uklinux.net> wrote:

> On Sun, Dec 17, 2006 at 10:19:21PM +0100, Ralf Stubner wrote:
>> 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. 
>
> Or we could break policy (no!!) :-)
> Or suggest modifying policy?

No, editor does not necessarily mean "interactive text editor".  It
can also be a "tool to interactively change configuration files", or to
do that on the commandline (texconfig-sys is both).  But each time a
configuration file is altered, it must be because the local admin
did something *now*, not because of any automatic mechanism (cron jobs,
maintainer scripts, or init scripts).

So it's no problem to have texconfig-sys, the problem would be to use it
to change conf(iguration)files in postinst.

>> > 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? 
>
> Handle it as a configuration file instead.  Look at the postinst of
> devscripts for one (simple) example.  Or use ucf.  Or something like
> that.

In short words, the package must

- create the file in postinst if needed (maybe after collecting
  information from the system or the debconf database)

- remove it upon purge

(these two points are the easy part)

- handle changes provided by an upgraded gracefully, preserving local
  changes. 

This is the hard part, and I wouldn't want to do it with a complete
config.ps.  A separate file that is supposed to only contain information
about the default paper size would be much easier - in particular if it
was a generated file in all cases and doesn't reside in /etc.

And we would *not* need to patch texconfig for this, since the libpaper
hook could do all the work.  We only would need to patch dvipdfm (which
is easy) and dvips (no idea how hard that is).

Regards, Frank
-- 
Dr. Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)



Reply to: