Andreas may still be running whole-distro rebuild tests, but enough results came back that I feel fairly confident saying that option B (remove the #include from stdlib.h) is a non-starter. There are too many (sloppily coded, yes) programs that include stdlib.h and expect it to expose all the POSIX foo_t types. That leaves us with option A (remove the #include from sys/types.h) and even that is going to break stuff. So we need a deprecation period. The attached, lightly tested, patch sets up that deprecation period. From an application's perspective, it works like this: * If you include directly, you get major(), minor(), and makedev() macros and everything works as it did before, regardless of whether you also include and in what order. * If you define _SYS_TYPES_NO_SYSMACROS before including any headers, then does not include at all. * If you include , you don't include , and you don't define _SYS_TYPES_NO_SYSMACROS, then you still get major(), minor(), and makedev() macros, but they trigger a deprecation warning if you *use* them. This warning contains a lengthy explanation of what is about to change and suggests either including or defining _SYS_TYPES_NO_SYSMACROS, depending on whether you actually wanted the dev_t manipulators. The implementation of all that is regrettably messy, but it works. I also took the opportunity to genericize some of the code involved; sys/sysmacros.h and makedev.c both now live in misc/ instead of sysdeps/, and there's a new 'bits' header that encapsulates the only thing that varies between Linux and non-, which is the actual encoding of a dev_t. (I'd appreciate extra-careful review of the arithmetic in the new bits headers; I'm not sure it was ever 100% correct, I may have messed it up, and there don't seem to be any tests.) I deliberately didn't say "in the next release" in the deprecation message, because we might want to give this more than one cycle to bake. zw