Re: #197870, #197891, #197954
On 18.09.03 Atsuhito Kohda (kohda@pm.tokushima-u.ac.jp) wrote:
> From: hille42@web.de
> Subject: Re: #197870, #197891, #197954
> Date: Wed, 17 Sep 2003 08:55:51 +0200
Hi,
> > Well, I don't think so. In the moment I have 2 suggestions:
> > 1. Move the whole thing into preinst stage. Disadvantage: All manual
> > modifications the user might have made in the extra-modules section
> > are lost
> > 2. We do something like:
>
> I understand your point but I doubt if it is really necessary
> because these handling of an old updmap would be done (normally)
> only when a user accepted a removal of the old updmap. So I see
> some duplication here.
>
You're right. Yet I don't understand so much about debconf. You may
beat me...
So, what about the following:
if [ -f ${etcdir}/updmap ]; then
db_input high tetex-base/oldupdm || true
db_go || true
db_get tetex-base/oldupdm || true
if [ X"$RET" = X"true" ]; then
touch /var/lock/updmap.rm
fi
fi
in debian/config and something like:
if [ -f /var/lock/updmap.rm ]; then
rm -f ${etcdir}/updmap
rm -f ${etcdir}/updmap.dpkg-*
rm -f /var/lock/updmap.rm
fi
in prerm or postrm? Is that against the Debian Policy? That is just
the solution I would use, if I had to program a shell script. Are
there mechanisms to make debconf decisions visible to other install
scripts?
We could leave a message in ${etcdir}/updmap, that this file is
obsolete, but today I think if the user decided not to remove it, he
should know what he's doing.
Hilmar
--
sigmentation fault
Reply to: