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. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]