With this move I've "fixed" libx11 no more depending at runtime on xorgproto package. I think no headers belong to an end user system and the libx11 library itself doesn't depend on it. But we also ship libx11-devel part inside the package and this indead depends on xorgproto headers. The libx11 .pc file clearly wants to have the headers installed. In the past it was enough to include libx11 to also pull in the proto headers at build time. This is now broken. Some devs call libx11 broken though only its -devel part is. After some discussion on IRC these solution are possible: a) revert to make libx11 depend again on xorgproto headers. This is the pragmatic way and would not need any further work. It just installs header files to the user system that aren't needed in any way there. So we did in the past and I don't really like it as it's not correct to me. b) stay with changed libx11 and add xorgproto to packages that check for any of its headers. This needs to be done to an amount of ~300 packages when hitting build errors over the next time. c) go an unusual way here and split libx11 into libx11, libx11-devel depending on xorgproto and maybe even libx11-xcb. This is the way distros go that support splitting libraries. It's probably the technical correct solution but will also require packages to makedepend on libx11-devel and save us no work. Other distributions have chosen what they prefer. That a decision that needs to be done downstream. I'd like to have either solution b) or c) in Arch to have a clear and more "transient" build time dependency. I guess it may help us also in the future when moving some day away from Xorg to its successor. But if majority wants solution a) back I'm fine reverting this change. Please vote. -Andy