Historical bug tracker for the Pacman package manager.
The pacman bug tracker has moved to gitlab:
https://gitlab.archlinux.org/pacman/pacman/-/issues
This tracker remains open for interaction with historical bugs during the transition period. Any new bugs reports will be closed without further action.
The pacman bug tracker has moved to gitlab:
https://gitlab.archlinux.org/pacman/pacman/-/issues
This tracker remains open for interaction with historical bugs during the transition period. Any new bugs reports will be closed without further action.
FS#38160 - [makepkg] building with different make dependencies
Attached to Project:
Pacman
Opened by Alexander F. Rødseth (xyproto) - Monday, 16 December 2013, 14:28 GMT
Last edited by Allan McRae (Allan) - Monday, 16 December 2013, 15:20 GMT
Opened by Alexander F. Rødseth (xyproto) - Monday, 16 December 2013, 14:28 GMT
Last edited by Allan McRae (Allan) - Monday, 16 December 2013, 15:20 GMT
|
DetailsBackground information
---------------------- Currently, there is an "erlang" and an "erlang-nox" package. Erlang is primarily targeted for server usage, so even though including X and GL support is default when building Erlang (and needed for ie. Wings3D), the headless "erlang-nox" version seems to be preferred among serious users of Erlang. However, Erlang builds differently depending on which packages are available on the system. As far as I am aware (and I have tried) there is no way to specify that Erlang should be built without support for X, as long as the relevant X packages are available. The actual feature request -------------------------- Can makepkg be changed so that not only package_packagename1() and package_packagename2() can be specified, with different 'depends' arrays, but also build_packagename1() and build_packagename2(), with different 'makedepends' arrays? My goal is to unite erlang and erlang-nox into a split package. (Also requested as a feature request for erlang-nox, here: |
This task depends upon
Closed by Allan McRae (Allan)
Monday, 16 December 2013, 15:20 GMT
Reason for closing: Won't implement
Monday, 16 December 2013, 15:20 GMT
Reason for closing: Won't implement
FS#38110, then. Thanks for the quick reply.