Revocation really is cancelling the certificate issuance -- the CA which has signed the certificate announces that it now denies it. A root CA being self-issued, it cannot be revoked. A root CA, by definition, is trusted a priori, not because its certificate was signed by some higher-placed CA in the hierarchy. Thus, there is nobody to emit revocation information that would be authoritative on that CA.
Some extra comments must be made, though:
You do not revoke a CA; you revoke a certificate. Any entity that has a name and owns a key pair, in particular a CA, may own several certificates. Each certificate is an assertion of that key ownership. What you think as a "root CA" may also be an intermediate CA in the following sense: besides its self-issued (traditionally self-signed) certificate, it may also have obtained another certificate that contains its name and its public key, and issued (signed) by another CA. The latter certificate, being issued by a distinct CA, can be revoked. This kind of situation is common in case of "root CA renewal" (a new root CA is created, and "cross-certificates" are issued so that the transition is smooth).
What certificates cannot do, maybe other systems can. For instance, a Web browser may contain a list of a priori trusted root CA (for validation of SSL server certificates); then, any update of the browser executable may add or remove root CA. There is no CRL involved, but it sure looks like a revocation mechanism, especially since modern browsers update themselves automatically. Windows has a similar system with a "disallowed" certificate store that acts like an OS-enforced, super-CRL which can make any certificate untrusted, even root CA certificates explicitly added to the store of trusted roots.
Trying to make a CRL containing the serial number of the compromised root, as was suggested in another answer, will not have the intended effect, for two reasons:
Systems that validate certificates (e.g. SSL clients when trying to verify the server's certificate) download CRL only for certificates where it makes sense, i.e. not for root CA, since they cannot verify the signature on the CRL save relatively to the public-key of the CA higher in the chain, since there is no such CA. You can write what you want in any CRL; if clients don't look at it, it won't get you far.
Even if you could somehow convince a client to download that "suicide CRL", where the root CA kills itself, remember that the private key have been compromised, thus the key thief may produce and sign a counter-CRL that says that everything is fine and nobody is revoked. Since the CRL download cannot be otherwise protected, the attacker can prevent that self-destruction mechanism to happen, even assuming that it would have worked with existing clients (and it does not).