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

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

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?


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

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: