Re: Taking over a previously diverted file
On 10/18/06, Steve Langasek <vorlon@debian.org> wrote:
So the constraints are:
- the old version of tetex-base must be removed before the new thailatex is
unpacked, otherwise you will have a file conflict
- there must be no /usr/share/texmf/tex/generic/babel/babel.sty in place
when the diversion is removed, because dpkg-divert --remove will throw an
error if the diverted-from file exists (whether or not the diverted-to
file still exists)
- any actions taken in the preinst must be reversible on failure, so that
the old package can be returned to installed state
Thank you very much for your analysis and advice. I have
tried it and it works.
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 ..." ?
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?
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?
This solution has the following properties.
- The version of tetex-base which contains $TEXDIR/babel.sty will always be
removed from the system before the postinst for the new thailatex is run.
(I chose this option over just Replaces:, because I'm not sure how
Replaces: would interact with a diversion.) This means that
$TEXDIR/babel.sty.real will not exist when the postinst runs.
As mentioned above, I wonder if Depends: tetex-base (>=$version)
is sufficient.
- 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]" ?
- By avoiding any use of the preinst, we also avoid any rollback
requirements.
OK. I have removed the code from preinst, and the problem is gone.
Completely untested in real-world conditions, let me know if you find I've
screwed something up :)
Thank you very much for your help.
--
Theppitak Karoonboonyanan
http://linux.thai.net/~thep/
Reply to: