[pkg-fetchmail-maint] Bug#276044: broken woody-sarge upgrade

[Jeremy S Bygott]

I'm sending this to two bugs (276044 and 268228) because it relates to
both. Sorry about the duplication.  They're really the same bug: the
broken woody-sarge upgrade.

I haven't contacted the submitter of 276044 (Dan Jacobson) but one
reason for his suggestion may be upgrade cruft.

>From my (fairly typical) woody-to-sarge upgrade, using aptitude:

<snip>

dpkg: fetchmail-common: dependency problems, but removing anyway as you request:
 fetchmail depends on fetchmail-common (= 5.9.11-6.2).
Removing fetchmail-common ...
Preparing to replace fetchmail 5.9.11-6.2 (using .../fetchmail_6.2.5-12_i386.deb) ...
Unpacking replacement fetchmail ...
Setting up fetchmail (6.2.5-12) ...

</snip>

Because fetchmail-common is only removed, not purged, it doesn't do
anything about the file /etc/default/fetchmail which was created by
the postinst of fetchmail-common (5.9.11-6).

Of course, /var/lib/dpkg/info/fetchmail-common.{list,postrm} are still
there, but if we aptitude-purge the now obsolete fetchmail-common, its
postrm breaks sarge's fetchmail.

My workaround was: purge fetchmail-common, purge sarge fetchmail,
reinstall sarge fetchmail.  [By the way, see also bug 288063.  These
steps should *not* destroy /etc/fetchmailrc.]

Of course, that is not the quality of upgrade that Debian strives for!

But Dan's suggestion for /etc/default/fetchmail does not deal with the
lurking obsolete fetchmail-common.postrm that will destroy fetchmail
when you least expect it!

I see now why sarge's /etc/init.d/fetchmail is so clunky (bug 268228).
But I don't think adding the fetchmail user back undoes all the
damage.  What about this part of fetchmail-common.postrm  ?

	if [ "$1" = "purge" ] ; then
	       	# Remove SysV initscript
		update-rc.d fetchmail remove >/dev/null || true

I can see three possibilities:

(1) Advise users to purge and reinstall.

(2) Try to make fetchmail resistant to the damage done by the postrm.
    We have no control over when in the future the postrm will
    explode, so we need to keep clunky code forever: for etch, etch+1,
    ...  We need to keep putting back the links and the user on every
    machine, just because someone may have the dodgy postrm.  Forever!
    Talk about legacy code ...

    For etch we also have to deal with /etc/default/fetchmail as per
    Dan's suggestion.
    
(3) Reintroduce fetchmail-common in etch, as suggested in the
    discussion of 268228, and make etch's fetchmail depend on etch's
    fetchmail-common.  We clean up all the mess in etch so that etch+1
    will be clean.

Option (3) means admitting we made a mistake, but then cleaning it up.
That seems better than option (2), which keeps needless code for long
into the future.  Imagine if every script had chunks like that left
over from old upgrade bugs!