> here is the full explanation :
> http://www.madism.org/~madcoder/295306.txt
does anybody has any advice ?
I explain it here again : the #295306 is a bug agains uw-imapd-ssl, but
in fact affects uw-imapd and ipopd/-ssl as well :
in the postrm of those packages, update-inetd --remove is called, even
if postrm was caled with 'upgrade'.
so, each time you upgrade uw-imapd, the postrm strips all imap2/3/s
entries of your /etc/inetd.conf, and then the configure (or postinst, I
can't remember) script enables them again ... but enables the defaults.
So I've fixed (and sent the fixed postrm) on the BTS, but that won't
close the bug, since it won't avoid e.g. the woody -> sarge upgrade to
trigger the bug.
The only way is to do some hackish things in the <new-preinst> since
it's the only script that will be called before the buggy <old-postrm>
until here, it's OK. but I readlly dunno which hack I have to implement
int the preinst. I have (at least) two choices, but I don't like any of
them :
(1) rm -f /var/lib/dpkg/info/uw-imapd.postrm (with the appropriate
version check)
- : this is truely horrible, moreover, postrm files may live elsewhere
- : this removes a dpkg file during it runs ... dpkg cannot be blamed
if he fails after such a thing
+ : this is small, and easy to understand
(2) parse /etc/inetd.conf and put the entries I don't want to loose
somewhere in /var/cache for a moment
and then use it in the postinst to feed inetd.conf
+ : this is really cleaner than the previous
- : this is really not trivial : inetd.conf is sorted by categories,
and it will be really difficult to put the entries at the right
place in the postinst
- : this fix will use quite a big amount of code, touch to many
scripts, and thereof may lead to new bugs, really more easily than
the previous "solution"
I can't see any (3) that isn't a new instance of (1) or (2), so any
advice is welcome.
--
·O· Pierre Habouzit
··O
OOO http://www.madism.org
Attachment:
pgpqpJRzl9zRe.pgp
Description: PGP signature