Hi Didier,
it seems that GNU ghostscript should have the following regressions
(unverified, but confirmed upstream for GPL ghostscript). Thanks to
Moritz Muehlenhoff <j...@inutil.org> for linking them in the debian bug
report.
Ray Johnston 2010-07-10 21:23:39 UTC
Some of the points to consider on this:
1. While GS_LIB=Resource/Init (or GS_LIB=./Resource/Init) works for finding
the init files, it does not automatically generate a valid default
GenericResourceDir since without -P (or -I.) Resource files cannot be
opened.
2. Without -P or -I. -sGenericResourceDir must be set to an absolute path
(even if the LIBPATH paths include relative paths).
3. When GenericResourceDir is set to a non-absolute path with -P- in effect,
whether set by -sGenericResourceDir or by the 'default setting' code in
gs_res.ps, it does not warn that the path is not valid. The testing in
gs_res.ps doesn't use the same algorithm as ResourceFileStatus does:
pssystemparams dup /GenericResourceDir get exch /GenericResourcePathSep get
Init) exch (gs_init.ps) concatstrings concatstrings concatstrings
status { ...
I am really unsure about the wisdom of changing the default behavior. If linux
distros wish to do this (to address security concerns raised by this bug), they
can do so, AND TAKE RESPONSIBILITY FOR TESTING AND/OR CHANGING ANY SCRIPTS
that break as a result.
(Regressions taken from
http://bugs.ghostscript.com/show_bug.cgi?id=691350#c17 )
If I did not miss any regression fix, the following upstream commits are
fixing these regressions:
r11499, r11500, r11510, r11514 and r11515.
Greetings from Germany
Markus Steinborn
GNU gv maintainer
PS: Debian currently plans to make "-dSAFER" the default with Debian
Squeeze+1, i. e. after the Release of Debian 6.0. The reason is to have
several month for testing this big change. You see applications and
scripts may get broken and need to be repaired.
