[arch-dev-public] libx11/xorgproto dependency

[Andreas Radke]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: Digitale Signatur von OpenPGP
URL: <https://lists.archlinux.org/pipermail/arch-dev-public/attachments/20191221/d40f50cb/attachment.sig>