Re: Taking over a previously diverted file
On Wed, Oct 18, 2006 at 09:47:43AM +0700, Theppitak Karoonboonyanan wrote:
> Some little questions, though:
> >Let's give this a try. In the postinst:
> >
> > TEXDIR=/usr/share/texmf/tex/generic/babel
> > if [ -e $TEXDIR/babel.sty ]; then
> > mv -i $TEXDIR/babel.sty $TEXDIR/babel.sty.undivert < /dev/null
> > fi
> > dpkg-divert --package thailatex --remove --rename \
> > --divert $TEXDIR/babel.sty.real \
> > $TEXDIR/babel.sty
> > mv $TEXDIR/babel.sty.undivert $TEXDIR/babel.sty
> Is there some specific reason for using "mv -i ... < /dev/null" ?
> It looks strange to me, but many times strange stuffs have
> their own reasons. Can it be "mv -f ..." ?
If $TEXDIR/babel.sty exists and $TEXDIR/babel.sty.undivert exists, the admin
has changed something by hand and we can't be sure any more which of these
is the file belonging to thailatex. Calling "mv -f" would ignore that
uncertainty; using "mv -i" treats that uncertainty as a reason not to
continue. (The < /dev/null avoids any prompts being sent by the maintainer
script: we just want to fail out, not interact with the user.)
This could also be written as
if [ -e $TEXDIR/babel.sty ] && ! [ -e $TEXDIR/babel.sty.undivert ]; then
mv $TEXDIR/babel.sty $TEXDIR/babel.sty.undivert
fi
which may indeed be a clearer way to write it.
> What happens if the "if [ -e $TEXDIR/babel.sty ]" clause fails?
> Does it mean the babel.sty.undivert won't be created and the
> second mv will fail?
The only reason that $TEXDIR/babel.sty should not exist here is if the
postinst has already moved it aside in preparation for the undivert. If
this clause fails for any other reason, that's a big (admin-induced)
problem, and the second mv will fail *by design* to avoid declaring the
package "installed" when files have been randomly removed...
> >and in debian/control:
> >
> > Package: thailatex
> > Conflicts: tetex-base (<< $version)
> > Replaces: tetex-base (<< $version)
> >From my experiment, it works without this change.
> Maybe, the Depends: tetex-base (>=$version) field already
> does the job?
Yes, it should.
> >- The script is idempotent; we know that $TEXDIR/babel.sty will exist the
> > *first* time the script is run, and that $TEXDIR/babel.sty.undivert
> > should
> > not exist, but we allow for the possibility that the postinst script
> > fails
> > later (before reverting the "mv") and that the user has manually fiddled
> > with files in between -- if the user has manuall added $TEXDIR/babel.sty,
> > the mv -i will silently fail, and the dpkg-divert --remove will /noisily/
> > fail.
> You mean, if user *removed* $TEXDIR/babel.sty?
> Yes, dpkg-divert --remove will complain, but its exit status is success,
> and the script continues, then the second mv will fail?
Yes.
> >- The diversion removal will always succeed unless the user has manually
> > adjusted files.
> >- The final mv will always succeed unless the user has manually adjusted
> > files, and as a result give us a $TEXDIR/babel.sty file that we're
> > assured
> > of being the copy from thailatex.
> I'm not so sure about this. Should the final mv be guarded with
> "if [ -e $TEXDIR/babel.sty.undivert]" ?
If $TEXDIR/babel.sty.undivert is missing, should the script succeed? I
believe that it should not, but there's no reason why your maintainer script
*must* fail in a situation like this.
Cheers,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
vorlon@debian.org http://www.debian.org/
Reply to: