[arch-dev-public] libx11/xorgproto dependency

[Eli Schwartz]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1601 bytes
Desc: OpenPGP digital signature
URL: <https://lists.archlinux.org/pipermail/arch-dev-public/attachments/20191221/0a2a0c94/attachment-0001.sig>