[arch-dev-public] libx11/xorgproto dependency

David Runge dave at sleepmap.de
Sat Dec 21 11:41:58 UTC 2019


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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.archlinux.org/pipermail/arch-dev-public/attachments/20191221/7388ee5e/attachment.sig>


More information about the arch-dev-public mailing list