Re: #197870, #197891, #197954

[Hilmar Preusse <hille42@web.de>]

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