Re: Policy, updmap --enable and updmap.cfg in /etc or /var
Hi,
Frank Küster <frank@debian.org> wrote:
> I had a look at this. You write in the comment of preinst:
>
> # Unfortunately, we are in preinst, so the package is not unpacked
> # yet, so we cannot simply copy $REF_CONFIG_FILE to
> # $TEMP_CONFIG_FILE. And I cannot do that in postinst because it
> # seems there is no way in postinst to know whether the previous
> # state was "purged" (not simply "removed").
>
> I do not see why it is necessary to know that. Why not do something like
> the following in postinst:
>
> if [ ! -f $CONFIG_FILE ]; then
> # the config file does not exist (i.e. not simply an upgrade).
That does not follow: if the admin deletes $CONFIG_FILE (which is
perfectly OK if he doesn't want lmodern in his map files but wants the
package to remain installed), then makes a simple upgrade, $CONFIG_FILE
is *not* present neither before, nor during, nor after the upgrade.
> if [ -f $TEMP_CONFIG_FILE ]; then
Are you sure you meant $TEMP_CONFIG_FILE? This is the one where I put
the default contents for $CONFIG_FILE before moving it (atomically, that
is the whole point of the trick) to $CONFIG_FILE on fresh installations.
[...]
> echo >&2 <<EOF
> Error:
> ...
> EOF
Good idea: I should do that in my postinst instead of the less readable
and more tedious to update construct:
{ echo "Error: $SAVED_CONFIG_FILE and $NO_CONFIG_FILE" \
"should not be present"
echo "at the same time on the system. If you did not" \
"fiddle with one of these"
[...]
} >&2
I'm snipping the rest of you script because I don't see it working
(starting from the $TEMP_CONFIG_FILE), or maybe don't understand it.
What we are trying to do is initialize $CONFIG_FILE if we are installing
from the 'purged' state. The problem with doing this in postinst is that
we can be in any of the following situations:
1) nothing in $STATE_DIR, and $CONFIG_FILE present: this is a simple
upgrade, and the admin did not delete $CONFIG_FILE;
2) nothing in $STATE_DIR, and $CONFIG_FILE absent: currently, with the
preinst I have written, this situation means that we are doing a
simple upgrade and the admin has deleted $CONFIG_FILE manually;
3) $SAVED_CONFIG_FILE (and only it) in $STATE_DIR: the package was
previously removed but not purged, and $CONFIG_FILE was saved to
$SAVED_CONFIG_FILE at that time; now, we are reinstalling the
package and are going to restore $CONFIG_FILE from
$SAVED_CONFIG_FILE unless $CONFIG_FILE has been recreated meanwhile
by the admin;
4) $NO_CONFIG_FILE (and only it) in $STATE_DIR: the package was
previously removed but not purged, and the admin had deleted
$CONFIG_FILE at that time; now, we are reinstalling the package and
are obviously not going to restore $CONFIG_FILE since the admin
wanted it deleted (in order not to have lmodern in his map files).
If you want to do the initial setup of the config file for fresh
installations (from the 'purged' state) in postinst, you have a problem
because you'll want to do it in the situation 2 above, but you have no
way to tell that this is not a simple upgrade with $CONFIG_FILE deleted
by the admin. That is why I decided to create the default config file in
preinst.
> Even if the preinst script is generated anyway (as I'm currently testing
> for tetex-3.0), I would prefer to copy the file from
> /usr/share/$package.
I understand, but for the moment, I haven't seen a better way to do it
(and haven't seen a flaw in the way I adopted).
There might be a way where we would drop some "flag" file in $STATE_DIR
on fresh installs from the preinst script, and then check in postinst
whether that file exists, and if so, copy the default config file from
/usr/share/$package to $CONFIG_FILE (and then delete the "flag" file).
I'd have to check a bit more whether it's really safe, but I'm not sure
it is worth it: it is really simpler?
Regards,
--
Florent
Reply to: