On 12/21/19 3:41 AM, Andreas Radke via arch-dev-public wrote:
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.
I'm not even sure I understand the question. The current state of affairs is that the libx11 package provides two things: - the libx11 client libraries - the libx11 development headers This is per standard Arch policy to not split headers into subpackages. Part of the feature functionality of the libx11 package is broken without xorgproto installed. *only* libx11 cares about xorgproto. What makes this "wrong"? The functionality that the package is intended to provide is indeed functionality that depends on xorgproto. It's not even merely pragmatic -- it is technically correct. ... People who are sincerely bothered by the installation of 1.5MB of headers should consider optionally adding a pacman.conf NoExtract rule to not install them; on my machine, it would save me 400MB, although personally I rather like headers since I tend to use them.
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.
This is unambiguously wrong, unless those 300 packages actually check for xproto.pc or kbproto.pc, which seems doubtful. The fact that it requires teaching hundreds of packages far too much about libx11 internals that they don't actually depend on is pretty annoying too, yes, but I'd argue this solution is technically incorrect either way.
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.
Is it the technically correct solution for just libx11, or for all packages? IMO this only makes sense if we do it consistently. Personally, the fact that Arch does *not* do this is one of the things I consider a great advantage over confusing distros like Debian.
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
-- Eli Schwartz Bug Wrangler and Trusted User