The NetworkManager package (0.4.0, 0.5.0, and 0.5.1) installs /etc/init.d/NetworkManager and /etc/init.d/NetworkManagerDispatcher but doesn't "chkconfig --level 345 <service> on" (or the like) to make them start by default. Seems like it should; otherwise users will have to do that or start those services manually to get NetworkManager running. I've been using 0.4.0 for a while, and I first noticed this problem when I upgraded to 0.5.0, at which point NetworkManager stopped starting automatically (which is strange, as I wouldn't expect upgrading the package to delete the relevant entries in /etc/rc.d/rc*.d). But I've since tested with the 0.4.0 package, and it doesn't seem to chkconfig the service on either, so perhaps I did that manually when I first installed it.
Arguably we should do this, but not sure if it makes sense to do this for users in an update... though part of the reason is that the FC4 version sucked initially... Tough call. In any case, it should be on by default in FC5. CC'ing others who may have thoughts.
I'm not convinced that changing the behavior in an update is the best solution - it shouldn't change the state of the links on a FC 4 box on update, though.
I did some more testing, and I can't reproduce the problem where NetworkManager stopped starting automatically. But I did notice that the /etc/rc.d/rc*.d/S98NetworkManager soft links get deleted when I uninstall the NetworkManager package, so I suspect I must have uninstalled 0.4.0 before installing 0.5.0, and that's what caused NetworkManager to stop starting automatically when I "upgraded" to 0.5.0. So that's probably not a bug, and perhaps you don't want to change this behavior in an fc4 update, but certainly in fc5 NetworkManager should start by default, so it should install the appropriate soft links into /etc/rc.d/rc*.d (or generate them in a trigger script).
FC5 Test 3 still isn't starting by default, which causes bug 182685.
This report targets the FC3 or FC4 products, which have now been EOL'd. Could you please check that it still applies to a current Fedora release, and either update the target product or close it ? Thanks.
Since there are insufficient details provided in this report for us to investigate the issue further, and we have not received feedback to the information we have requested above, we will assume the problem was not reproducible, or has been fixed in one of the updates we have released for the reporter's distribution. Users who have experienced this problem are encouraged to upgrade to the latest update of their distribution, and if this issue turns out to still be reproducible in the latest update, please reopen this bug with additional information. Closing as INSUFFICIENT_DATA.