Mara does not resolve ncs.gov

[Rick Moen]

Quoting Sam Trenholme (strenholme.usenet at gmail.com):

> Do they even make sure there are conversion scripts that convert all
> relevant configuration files from one version of a given daemon to the
> next version?

Mu.  ;->

I can't remember all details, but the general technique does _not_
aspire, in any way, to convert raw conffiles from an old version's data
format to an incompatible new implentation's format.  Instead, when you
first install a package with significant configuration variations, you
are prompted (through the services of the debconf[1] utility) for your
choices on the basis of which the conffiles get written.  debconf stores
your answers to those questions in .templates files.  When it's
necessary to reimplement your configuration in a later and perhaps
marginally compatible later version of the package, your answers are
reapplied.  

This is of course not a magic bullet:  You can easily have situations
where you've directly hacked a system-managed conffile; it's debconf's
duty in those cases to inform you of this situation and offer various
options to deal with the diffs.  However, there's been a strong tendency
to ameliorate this category of problem by extracting locally-managed
details out of software conffiles as include files (or equivalent)
separate from the system-managed main conffile, so that smooth upgrades 
remain possible while usually avoiding what one might call the .rpmnew /
.rpmsave problem.

And indeed some changes are such sea changes that they're only arguably
the same program at all:

> For example, the BIND 4 -> BIND 8 config file conversion was
> non-trivial;

It was also so very long ago (1997) that neither Debian nor any other
*ix even dreamed of handling named.boot to named.conf conversion
programmatically.  ;->  (Joey Hess didn't even have debconf production
ready until around 2000.)

> in addition, I think Apache made some pretty significant changes from
> Apache 1 -> Apache 2.

And that's why apache2 is a different package from "apache" (1.3.x).

You can keep your old 1.3.x "apache" packages going, as you go from one 
stable release to another -- and they'll keep getting security updates
and fixes.   It won't break; it'll keep running.  It won't magically
turn into Apache2, which is different software.  Eventually, at some
point, though, it'll cease to be a supported package, and then you won't
get further updates.  In the case of the "apache" package, that's going
to happen with Debian 6.0 "Squeeze"'s release.  See:
http://www.debian.org/releases/stable/i386/release-notes/ch-upgrading.en.html#deprecated

(All of the above also applies in one way or another to all
Debian-family distributions, such as the *buntu group.  E.g., they all
use debconf, separately named packages for Apache httpd 1.3.x vs. 2.x,
and so on.)

[1] http://www.fifi.org/cgi-bin/man2html/usr/share/man/man8/debconf.8.gz