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

Re: #197870, #197891, #197954



On 16.09.03 Atsuhito Kohda (kohda@pm.tokushima-u.ac.jp) wrote:
> From: Hilmar Preusse <hille42@web.de>
> Subject: #197870, #197891, #197954
> Date: Mon, 15 Sep 2003 19:59:02 +0200

Hi,

> > In the config-stage of tetex-base-2.0.2 we do something like:
> > 
> > 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
> >         rm -f ${etcdir}/updmap
> >         rm -f ${etcdir}/updmap.dpkg-*
> >     fi
> > fi
> > 
> > . That causes the mentioned bugs (or one could say it is caused by
> > the buggy pxfonts-package). Unfortunately I don't understand why we
> > do that. Could anybody be so kind to enlighten me? ${etcdir}/updmap
> > will be removed anyway during remove as it belongs to tetex-base.
> > Maybe there will be a updmap.dpkg* left as it is marked as
> > configuration file. We could leave a message in the updmap-file if we
> > hand over the removal-job to dpkg.
> 
> Well, please remark that
> 
> - ${etcdir}/updmap itself is a conffile so not removed
> during "remove", especially it is not removed during
> "upgrade".  So there could be two updmap in a system, one is
> an obsolete ${etcdir}/updmap and the other is a new /usr/bin/updmap.
> 
> - further, when one upgraded tetex-base then ${etcdir}/updmap 
> did not belong to tetex-base anymore so not a conffile, which means 
> that even when one purges tetex-base afterwards ${/etcdir}/updmap 
> will be not removed.
> 
> So I guess we need to do the above.
> 
OK, understand. I forgot to mention, that perhaps we can move that
step backward to the prein or the postin stage cause at this time the
prerm-Script of pxfonts should already have been executed.

> The simplest fix would be modifying as follows?
> 
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:

<snip>
    if [ X"$RET" = X"true" ]; then
	cat > ${etcdir}/updmap.new << EOF
#!/bin/sh
#### ***** This file is obsolete *****
#### ***** This file is obsolete *****
#### ***** This file is obsolete *****
####
#### Please port your local modifications to the new updmap.cfg-file.
#### This is done either by creating a new file in /etc/texmf/updmap.d/
#### and running update-updmap or by modifying /etc/texmf/updmap.cfg
#### directly. Which method to use depends on whether you decided to
#### automatically create your updmap.cfg or not.
EOF
	cat ${etcdir}/updmap >> ${etcdir}/updmap.new
	mv -f ${etcdir}/updmap.new ${etcdir}/updmap
        rm -f ${etcdir}/updmap.dpkg-*
    fi
<snap>

and let debconf additionally spit out an appropriate message at
install time.

Regards,
  Hilmar 
-- 
sigmentation fault



Reply to: