Clarifying the purpose of /etc/papersize?
Hello,
I regularly read messages on the Debian lists about packages that do
not use /etc/papersize but should. I got the impression that
/etc/papersize was meant to contain live information about the paper
size used on a given system, and that programs should read it when
they need a default paper size (they can of course take papersize from
the command-line or user-specified configuration file).
This usage seems logical to me, because it means that the name of
the default paper to use can be changed when needed in /etc/papersize
with the net effect of having all programs getting a default value from
this file taking the change into account.
I discussed this question with other developers and one had the
understanding that /etc/papersize was meant to be used only during the
installation of a package (which will not notice any change to this file
after installation), the installation scripts reading the /etc/papersize
value and putting it into the right configurations files for the installed
package, if it has some (which is not the case of a2ps or psutils for
example).
This sounds plausible too, so I'm now unsure of the true purpose of
/etc/papersize :-(
I'd like to know what you do think about the role that /etc/papersize
should play on a Debian system. Maybe should we ask Debian users too,
so this might not help to reach a consensus.
For my part, I favor the use of /etc/papersize for getting a runtime
default instead of a compiled one. I'd like to suggest that programs
that handle paper size on Debian replace the use of something like
-DPAPER='"a4"'
with
-DPAPER="systempapername()"
the latter requiring that the program be linked to a specific libpaper
library that would, among other things, be able to get the default
page size from /etc/papersize (and eventually from a PAPER env. var).
I wrote such a small library and tested the modification of a2ps and
psutils: a2ps's changes where 5 lines long (adding an error message
if the paper name is unknown), and psutils was easily changed too
to support the libpaper library (and changing manual pages according
to its use or not). The fact that adding basic support for a
system-wide paper default with minimal efforts is possible is essential
to encourage such changes.
In addition to letting programs use /etc/papersize, the libpaper
library helps them support 40 different paper names out of the box.
It also comes with a simple program printing information about a
paper to help writing wrapper scripts (like a wrapper for gs:
gs -sPAPERSIZE=`paper` "$@").
To me this has a big advantage: runtime configuration at no cost for
existing packages, without requiring installation scripts or
reinstallation of packages when the system paper change (or editing
wrapper scripts). Another advantage is that centralizing some
functions to manipulate paper names (and not only size) means that
improvements to the set of functions for manipulating papers will
benefit all the programs using such a library. (At the moment, they
only get new paper size, but that's a start).
It has also some disadvantages: modified packages depend on the
libpaper library, which introduces another depends/conflict; existing
scripts that rely on a well-known compile-time default for paper
size may break (I don't have any, but other may); it does not encourage
package developers to develop site- and user-configuration files
(but I won't do one just for a2ps or psutils, for example).
I'd like to get your opinion on this.
Thanks,
Yves.
Reply to: