Currently `pkg install flang` gives the below error:
> The following packages have unmet dependencies:
> flang : Depends: libllvm (= 18.1.7) but 18.1.7-1 is to be installed
> Depends: clang (= 18.1.7) but 18.1.7-1 is to be installed
> Depends: lld (= 18.1.7) but 18.1.7-1 is to be installed
> Depends: mlir (= 18.1.7) but 18.1.7-1 is to be installed
> E: Unable to correct problems, you have held broken packages.
This is due to the `(= $TERMUX_PKG_VERSION)` dependency qualifier on
llvm dependencies, introduced in 50737838a5344f1e128f4164b90af07378945cc0
to make sure that llvm matches the flang version.
This is fine for the upstream version (version `18.1.7` of flang should
depend on version `18.1.7`).
But when bumping the `TERMUX_PKG_REVISION` on llvm, which was done in
58811a96a6db7f8282bd8e1ad2c99b44d0b1b253, it results in a problem such as
we have now: flang `18.1.7` depends on exactly `18.1.7`, while the
repository has `18.1.7-1`.
Ideally we would probably want to ignore the package revision, and
allow all revisions of flang 18.1.7 to depend on all revisions of llvm
18.1.7 - effectively a revision wildcard. Is that possible with debian
version qualifiers?
This patch just bumps the `TERMUX_PKG_REVISION` of `flang` and uses that
to match the current llvm revision in the dependency, so that the flang
package is installable again. If we can't come up with a better approach
short term we can probably go for this now to make the package
installable again.
Reported by @timstrom in https://github.com/termux-play-store/termux-packages/issues/3
Some packages have issues with parallel builds and need to set
TERMUX_MAKE_PROCESSES=1. All other build variables that package
recipes set are prefixed with TERMUX_PKG, use that for MAKE_PROCESSES
as well for consistency.
%ci:no-build
