My hard disk was recently corrupted. Unfortunately, most of the corruption was to various subdirectories of /etc/init.d, so I had to erase the corrupt directories and rebuild /etc/init.d/rc*.d. I tried both "rpm -U --force initscripts-6.40.2-1.i386.rpm" and "rpm --install --force initscripts-6.40.2-1.i386.rpm". Both of those commands ran, and "rpm --verify initscripts" says that there are no problems, but neither of those commands regenerated missing symlinks, e.g., /etc/rc.d/rc6.d/S01reboot. I see that the symlinks are marked %config(missingok) in the spec file. I believe this means that "rpm --verify" isn't supposed to complain about them being missing, but does it also mean that upgrading or reinstalling shouldn't create them if they're missing? I find that hard to believe, but if that is, indeed, correct behavior, then I think it's a problem to mark these links "missingok", because it makes it very difficult to recover from corrupt initscripts by reinstalling the package.
What happens if you remove the old package, and then install it?
Unintalling and reinstalling works. This is not surprising. It's also not really an answer this bug. Reinstalling should work as well. You can't expect people to know that for this particular package they need to uninstall before they can reinstall, especially since rpm won't even let them uninstall unless they specify --nodeps. Not to mention the fact that uninstalling initscripts is rather dangerous -- what happens if your machine crashes in between when you uninstall and when you reinstall?
Assigning to rpm; this doesn't really have anything to do with initscripts in particular.
And this is exactly rpm %config(missingok) behavior. Since the symlinks are part of runtime configuration, there's simply no way to solve the problem in packaging. Creating a symlink where there was none before is as much a problem as not recreating a link.
Fine, in that case, I don't think this is an rpm bug, I think it's a bug in the initscripts packaging. These links should not be "missingok". I can't think of any sane configuration in which these links would be missing. Even if there is such a configuration, it's surely a very small percentage of total initscripts installation -- that is, if these links are missing, it's much more likely that it's because there's a problem with the machine than because the sysadmin removed the links intentionally and wants them to stay that way. Therefore, the links should not be marked missingok -- let the few admins who really mean for them to be missing to deal with the extra "rpm --verify initscripts" output and recreation of these links on upgrade, while for everybody else, the package will behave in a saner, safer manner.
Your suggestion presumes that the links that should be created is known at package install time, very often not the case. Heck the runlevel isn't even known at initscripts package install time, it depends on whether you want a GUI/TUI login. Look, your analysis is dead on, but is insoluble within constraints imposed by current technology. Is DEFERRED OK with you? Just don't hold your breath for a solution. *Really*
I don't think I understand the point you're trying to make. All I'm proposing is that the links which the initscripts package already creates when it is initially installed get recreated when it's reinstalled. Could you clarify why that's a hard problem? I don't get it.