On 2013-02-13 16:37, Dirk Eddelbuettel wrote:
> | There is one file being modified in the postinst script: Renviron.ucf.
> | That seems be be caused by some logic flaw originating from the time
> | when the configuration file in /etc was modified directly:
> | ## test if the file is unmodified `as shipped'
> | Renviron.ucf will be unmodified everytime (except when running
> | dpkg-reconfigure r-base-core), so the correct workflow for the postinst
> | should be something like
> | mktemp ; sed ; ucf ; rm
> | (generate default config from template in a temporary file, install this
> | via ucf, clean up afterwards).
>
> Likewise, I have no real interest (or time) in getting into conf file
> exercises-for-exercises sake debates. What we have now works, and A LOT of
> peope rely on this package.
Modifying shipped files is *not OK*. Hiding it in md5sums -X is *not OK*.
> How precisely does your patch address this?
Not at all. But probably the following postinst snippet will do
(untested!):
# edd 19 June 2004 deal with papersize
# edd 22 June 2004 make that conditional on paperconf
# edd 25 Oct 2006 rewritten for R 2.4.0 and R_PAPERSIZE_USER
# edd 21 Jun 2008 rewritten for R 2.7.1 and ucf input
tmpRenviron=$(mktemp)
cat /usr/lib/R/etc/Renviron.ucf > $tmpRenviron
if [ -x /usr/bin/paperconf ]; then
## get the value we want from Debian's paperconf utility
papersize=`paperconf`
## have perl subst. second expression with $papersize for first
## uses the x mod. and curlies to denote the usual s|1st|2nd|
perl -p -i -e "s{^R_PAPERSIZE_USER=\\$\{R_PAPERSIZE\}}
{R_PAPERSIZE_USER=\\$\{R_PAPERSIZE-'$papersize'\}}x"
$tmpRenviron
fi
# edd 21 Jun 2008 whether or not Renviron was modified, ucf will handle it,
# so tell ucf that file Renviron.ucf is the source for
# conffile in /etc and register it
ucf $tmpRenviron /etc/R/Renviron
ucfr r-base-core /etc/R/Renviron
rm -f $tmpRenviron
#
May need reindenting and comment adjustments.
May need a chmod 644 $tmpRenviron after the mktemp.
And maybe consider shipping Renviron.ucf as Renviron.template
or Renviron.default (or whatever) instead.
> Will we not trigger lots of
> false positives? Is there a way to avoid that?
False positives of what?
Andreas
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]