On Thu, 03 Feb 2011 21:30:26 +0100 Sven Joachim wrote: > On 2011-02-03 19:18 +0100, Eddy Petrișor wrote: [...] > > So the way to reproduce is probably install apt-listbugs and then remove it. > > I failed to reproduce this.
Hi Sven,
many thanks for contributing to the discussion in a constructive way!
:-)
It definitely seems that I am not the only one who fails to reproduce
the bug (thanks for confirming!).
> However, there is a bug: if apt-listbugs is
> in the "Config-Files" state and a to-be-installed new version fails to
> unpack, you get into the situation you described.
Mmmmh, this seems to make sense: I had not thought about this possible
scenario...
>
> The postrm script should rename the file back to 10apt-listbugs.disabled
> when called with the "abort-install" argument to take care of this
> possibility,
Maybe I could add the following snippet to the postrm script:
abort-install)
if test "x$2" != "x" && test -f $hook
then
mv $hook $hook.disabled
fi
;;
and of course drop abort-install from the do-nothing case.
I have to test this solution...
> or maybe your patch should be applied, since renaming
> conffiles in maintainer scripts looks rather fragile to me.
This could be a more robust solution, but I have to understand how the
transition from the old strategy to the new one can be managed (since
someone could have an old version in the "Config-Files" state and
install a new version, someone else could try to downgrade, and so
forth...).
--
http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt
New GnuPG key, see the transition document!
..................................................... Francesco Poli .
GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE
pgpGaAirvwDAk.pgp
Description: PGP signature
