Re: [arch-dev-public] libx11/xorgproto dependency
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 signature.asc Description: OpenPGP digital signature
Re: [arch-dev-public] libx11/xorgproto dependency
Am Sat, 21 Dec 2019 19:47:39 +0200 schrieb Evangelos Foutras via arch-dev-public : > @Andreas: Can you go ahead and add xorgproto back to libx11? Better to > have 1.5 MiB of headers installed than add seemingly unrelated > xorgproto build dep to packages failing to build or have features > suddenly going missing from packages. Yes, I'm going to add it back. Sorry for the noise. -Andy pgp_eEADkkJ25.pgp Description: Digitale Signatur von OpenPGP
Re: [arch-dev-public] libx11/xorgproto dependency
On December 21, 2019 9:41:46 AM GMT+01:00, 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. > >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 I'm voting for b) or c). If there aren't really any further deps, personally to me it doesn't really matter too much to combine them, however for compile additions I prefer independence. btw we also have xorg-server-devel Cheers Levente
Re: [arch-dev-public] libx11/xorgproto dependency
On Sat, 21 Dec 2019 at 18:13, Jan Alexander Steffens via arch-dev-public wrote: > > We now have many packages that want libx11 but say nothing about *proto, > yet they now need xorgproto as a makedepend. > Even worse, this extends further downstream, and packages building against > GTK now also need a makedepend on xorgproto. I also noticed tumbler was deciding to disable its poppler plugin at build time; adding xorgproto to makedepends fixed it. So this can cause silent change of build options too, in the case of auto-detected features. @Andreas: Can you go ahead and add xorgproto back to libx11? Better to have 1.5 MiB of headers installed than add seemingly unrelated xorgproto build dep to packages failing to build or have features suddenly going missing from packages.
Re: [arch-dev-public] libx11/xorgproto dependency
On Sat, Dec 21, 2019 at 12:42 PM David Runge wrote: > I'd go for b) as to me it seems the more correct approach (and doesn't > require introducing further packages). Additionally, it is reflected in > the package guidelines [1]. > Unfortunately I think the guideline isn't very clear on what it means. It is thus: Build system of program A wants libraries B and C. Library B depends on C. You should add both B and C to A's depends. But if the build system of program A wants only library B, you should not add C to A's depends. We now have many packages that want libx11 but say nothing about *proto, yet they now need xorgproto as a makedepend. Even worse, this extends further downstream, and packages building against GTK now also need a makedepend on xorgproto. I made a rough estimation and end up at ~3500 packages that are now broken. Grepping for 'Requires:.*\wproto' through my local pkg-config files, these packages directly reference a *proto and should have a dep on xorgproto: libice libx11 libxau libxaw libxcomposite libxcursor libxdamage libxdmcp libxext libxfixes libxfont2 libxft libxi libxinerama libxkbfile libxmu libxrandr libxrender libxres libxss libxt libxtst libxv libxxf86vm
Re: [arch-dev-public] libx11/xorgproto dependency
On Sat, Dec 21, 2019 at 12:18 PM Allan McRae via arch-dev-public < arch-dev-public@archlinux.org> wrote: > On 21/12/19 7:31 pm, Evangelos Foutras via arch-dev-public wrote: > > Downstream consumers of libx11 shouldn't have to know and account for > > libx11's headers/pkg-config files referencing xorgproto. A > > libx11-devel package would depend on xorgproto. Since there's no > > separate -devel package, the dependency stays with the regular libx11 > > package. > > This matches my opinion on the matter. > Ditto. (a) and (c) are the technically correct solutions, and I prefer (a). Unless we want to start a distro-wide effort of splitting out -devel packages, that is.
Re: [arch-dev-public] libx11/xorgproto dependency
First of all, thanks for doing the cleanup! :) On 2019-12-21 09:41:46 (+0100), Andreas Radke via arch-dev-public wrote: > Please vote. I'd go for b) as to me it seems the more correct approach (and doesn't require introducing further packages). Additionally, it is reflected in the package guidelines [1]. I think, that the overhead of changing the packages is of course a reality, but also part of being a packager and changes like these don't happen every day. As reference: I've done a similar thing for the lv2 [2] package (which is a makedepend for all lv2 plugins and hosts, but not required at runtime) and ladspa [3] (which is a makedepend for all ladspa plugins, but not required at runtime). In the specific case of lv2 similar rules apply, as we don't have -devel packages (which is great) for e.g. suil or sratom (that require lv2 to build other things). However, upstream is currently about to change the way host applications are supposed to be build by moving all the disjointed libraries into a new conglomerate library (and is en route to introduce breaking changes to lv2). I'd rather stay overly explicit and pull in dependencies where they are needed (e.g. makedepends), which makes it more transparent to change in case of upstream change, than to rely on transitive dependencies. Best, David P.S.: I'd also love to see the provided shared libraries be exposed in the provides array of libx11 (i.e. libX11.so and libX11-xcb.so) [4]. [1] https://wiki.archlinux.org/index.php/Arch_package_guidelines#Package_dependencies [2] https://www.archlinux.org/packages/community/x86_64/lv2/ [3] https://www.archlinux.org/packages/extra/x86_64/ladspa/ [4] https://wiki.archlinux.org/index.php/Arch_package_guidelines#Package_relations -- https://sleepmap.de signature.asc Description: PGP signature
Re: [arch-dev-public] libx11/xorgproto dependency
On 21/12/19 7:31 pm, Evangelos Foutras via arch-dev-public wrote: > Downstream consumers of libx11 shouldn't have to know and account for > libx11's headers/pkg-config files referencing xorgproto. A > libx11-devel package would depend on xorgproto. Since there's no > separate -devel package, the dependency stays with the regular libx11 > package. This matches my opinion on the matter. A
Re: [arch-dev-public] libx11/xorgproto dependency
Downstream consumers of libx11 shouldn't have to know and account for libx11's headers/pkg-config files referencing xorgproto. A libx11-devel package would depend on xorgproto. Since there's no separate -devel package, the dependency stays with the regular libx11 package. You already called (a) the pragmatic approach and it seems like a no-brainer at 1.5 MiB installed size. If we go with (c), it might be worthwhile to mass edit packages in /trunk to add the build dep. Doing that manually for hundreds of packages is a huge time sink and quite annoying during rebuilds.
Re: [arch-dev-public] libx11/xorgproto dependency
El 21/12/19 a las 9:41 Andreas Radke via arch-dev-public escribió: > 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. I'm fine with either (a) or (b), both can be seen as correct for some definition of "dependencies". But please not (c), it doesn't really fix anything and it's an unnecessary divergence from our usual practice of not having split devel packages.
Re: [arch-dev-public] libx11/xorgproto dependency
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 pgpko15n59YzQ.pgp Description: Digitale Signatur von OpenPGP
