You are not logged in.
The package: llvm35 has an empty "provides" field. This is important for: python-llvmlite which cannot use the newest llvm in the official repos. Since llvm35 doesn't provide 'llvm' makepkg refuses to build python-llvmlite unless you hit it with a hammer.
Offline
I see that it already *conflicts* with llvm, so there should be no problem giving it a provides field as well. You should open a request on the bug tracker.
Offline
The package: llvm35 has an empty "provides" field. This is important for: python-llvmlite which cannot use the newest llvm in the official repos. Since llvm35 doesn't provide 'llvm' makepkg refuses to build python-llvmlite unless you hit it with a hammer.
Is there anything that works with llvm that does not work with llvm35? If a single package does not, llvm35 can not provide llvm.
Offline
Mesa 11+ works with older llvm (pre 3.6 I think) but is unable to expose GL4 on hardware that suports it. Is that a reason enough for llvm35 not to provide llvm?
Offline
Something in mesa links to libLLVM.so.3.7. So that is enough.
Offline
The lack of provision is intended. I don't want llvm35 to be used for anything other than building software which hasn't been ported to LLVM>=3.6 yet.
Packages that need it should makedepend on llvm35 directly (i.e.: not use a versioned llvm dep). Same goes for the llvm35-libs runtime dependency.
Finally, llvm35 will be dropped as soon as nothing in the repos requires it.
Example scenario where provides=('llvm') could cause trouble:
1) User builds python-llvmlite which brings in llvm35.
2) User proceeds to build mesa; llvm35 satisfies mesa's llvm build dep.
3) The resulting package group links to libLLVM-3.5.so but depends on llvm-libs which ships libLLVM.so.3.7.
4) Sometime in the future, after removing llvm35-libs: "Oh noes, X is not starting!"
Offline
Thank you for the responses. Even if it is not the best answer, at least now there is a rationale for not having the package provide llvm.
Offline