upgrade path for distributions

[Alan DeKok]

Stephen Gran wrote:
> I've been looking at the freeradius 2.0pre versions, and first, I want
> to say nice work.  The new features look wonderful.

  Much, much, better.

> I'm a little concerned about the upgrade path for distributions, though,
> and I wanted to raise it as an issue for consideration.  I am fully
> aware that it may be unfixable.  It appears now that a 1.x config file
> will not be parsed by a 2.x server, and you'll be left with a
> non-functioning radius service after an upgrade.

  There is that distinct possibility.  While every effort has been made
to ensure backwards compatibility, some things just aren't worth fixing.

> This makes me feel like the right upgrade path for distributions is to
> ship the new version as freeradius2 (complete with /etc/freeradius2,
> /usr/sbin/freeradius2, and so on).  This would allow admins to coinstall
> the two versions, and plan an orderly migration, rather than just break
> the existing setup.

  I understand... but it's pretty awkward.  How is this handled for
other packages?

> I'm just hoping to put the issue on people's radar if it is able to be
> worked around.  If it's not, then I'll just bite the bullet and make the
> divergence, but I was really hoping not to.

  I *really* don't want to see a "freeradius2" anywhere.  It's already
confusing enough to have Debian install the binary as "freeradius",
rather than "radiusd".  Since the existing Debian "radiusd" binaries are
from RADIUS servers that haven't been maintained for years, people get
confused.

  Anyways... I'm not sure what to do here.  Breaking peoples existing
systems is bad, but upgrading is useful, too.  I *don't* want Debian to
take the RedHat route of shipping versions of software that are 5 years
out of date...

  Alan DeKok.