Comment 14 for bug 453365

> Now, if you chain that with the openafs upstart job waiting for DKMS to
> be done and apache/mysql/$favorite_server_service waiting for network
> file systems to be ready and you've got a very logical ordering to your
> boot process.

Yes yes, I understand that. And I want very much to live in that world. But we aren’t going to get there overnight, or even in one release cycle (especially with packages being imported from Debian, which still uses SysV initscripts). So I’m interested in making the transition to that world as smooth as possible, especially when it’s easy.

OpenAFS certainly wants to satisfy a network file systems event—but again, if openafs depends dkms and dkms runs after rc, then now you’ve forced rc to never depend on network file systems.

Someday rc will go away and none of this will be a problem, but until then let’s try to get things right with rc.

> I'll have to see how this setup behaves if DKMS loads before the legacy
> SysV services, particularly since that might trigger things rather than
> gdm as originally intended for the desktop case.

You mean you’re worried about dkms triggering things too early? dkms does not trigger anything yet, and when there are packages that trigger on dkms, they will ‘start on (stopped dkms_autoinstaller and <other conditions…>)’ so that they won’t trigger too early no matter how early dkms finishes.

Better yet, you could register an event (say) built-module, and do ‘initctl emit built-module MODULE=foo’ for each module foo when it is built, so that other services could “start on (built-module MODULE=foo and <other conditions…>)”.

By the way, you can use the starting-dm event instead of ‘starting gdm or starting kdm or starting xdm’.