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_depende... [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_relatio... -- https://sleepmap.de