Comment 21 for bug 453365

> --- debian/gdm.upstart 2009-12-11 05:36:55 +0000
> +++ debian/gdm.upstart 2009-12-14 20:12:34 +0000
> @@ -9,7 +9,9 @@
> start on (filesystem
> and (graphics-device-added fb0 PRIMARY_DEVICE_FOR_DISPLAY=1
> or drm-device-added card0 PRIMARY_DEVICE_FOR_DISPLAY=1
> - or stopped udevtrigger))
> + or stopped udevtrigger)
> + or build-successful MODULE=nvidia
> + or build-successful MODULE=fglrx)
> stop on runlevel [016]
>
> emits starting-dm

I’m a little worried that this has race conditions:
• If build-successful fires before the graphics device is ready, gdm startup may be triggered too early (is this a problem?).
• If build-successful fires between the time X fails to module and the time gdm finishes failing to start, the event will be lost entirely.

Maybe one way this could be solved is to leave gdm the way it was and add a dummy task to the nvidia and fglrx packages to block gdm from starting up before the module is available. This avoids any race conditions that involve trying to start the gdm job multiple times, and also seems more neatly modular:

  start on starting gdm and (build-successful MODULE=nvidia or build-failed MODULE=nvidia)
  task
  exec /bin/true

(Given that use case, perhaps build-failed should not actually be a separate event? It might be nicer to emit events like
  dkms-build MODULE=nvidia RESULT=successful
  dkms-build MODULE=nvidia RESULT=failed
so that one can wait for dkms-build MODULE=nvidia without needing to indicate which.)

Should I file a separate bug?