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

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



On Fri, Dec 15, 2006 at 15:46 +0100, Frank Küster wrote:
> Stephen Gildea <stepheng+debian-bts@gildea.com> wrote:
> 
> > Tetex should work out of the box; it should not be necessary for a
> > sysadmin to know to change a /etc/default file.  
> 
> teTeX does work out of the box, it produces correct paper for those who
> know how to write their documents.  Only the lazy folks who never have
> changed their habits since the old days need to configure the papersize
> site-wide.  I never had the wish to do anything of that sort.
> 
> In my opinion, all this specifying of the papersize after document
> processing is legacy. 
[...]

ACK

> > Asking a debconf
> > question, "do you want tetex's paper size managed by libpaper", at
> > least alerts sysadmins to the possible problem, and at best allows a
> > "yes" answer to be pre-seeded.
> 
> 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. I am
reluctant to go for a debconf question for a different reason, though.
IMO we must not just ask 'Should pdftex/dvips/dvipdfm use libpaper for
papersize setting?' but have to make two things clear: First, that this
will require editing conffiles, and second, that this does only
indirectly affect where ink is put on paper. Mainly the papersize
information written into PS and PDF files are changed. 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. In addition, up to now I have had the impression that
coding with debconf is quite complicated. But I might be wrong here.

Anyway, if we make a debconf question, we need:

- a well formulated question

- What priority should the question have?

- 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 ...

- 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. 

cheerio
ralf




Reply to: