Nope. It's a change in policy; we don't want to start named
automatically if installed anymore. chkconfig --add shouldn't
change existing links, though (if it does, that is a bug).

Of course, now I look at the package and see that the scripts
that it includes don't mesh with this. Will fix.

The "chkconfig: - 55 45" line works to make named install by default
as non-running, but the problem is that I can't enable the service
using chkconfig... that line basically "short-circuits" chkconfig's
definition of the service running so that "chkconfig --add named" and
"chkconfig --del named" have the same effect. To enable the service I
have to manually create the symlinks. The whole purpose of chkconfig
was to keep me from having to manually create these links.

Wouldn't it just be better to leave the "chkconfig: 345 55 45" line
alone and change the "chkconfig --add" line in the postinstall script
to "chkconfig --del" to implement this policy change?

Actually, the chkconfig behavior works like this:

chkconfig --add adds the default links specified in the
init file.
chkconfig --del removes *all* links.

To enable a service using chkconfig, regardless of the initfile
defaults, do something like:

chkconfig --level 345 named on

(The --level argument is a list of runlevels. --level <foo> is
optional.)

Oh, that's funny. I've been using chkconfig wrong all this time and
I've not gotten bitten yet. :-) Sorry about the erroneous bug report.

That's OK. At least it caused me to notice the
bind chkconfig & links disagreeing. :)