On 16-04-2019 15:29, Doug Newgard via aur-general wrote:
Is there any reason it depends specifically on the -git package? Most of the time, you depend on the release package and those that use the -git version just build against that, no other changes needed.
On 16-04-2019 15:33, Bruno Pagani via aur-general wrote:
Hi,
Are AUR VCS packages that depend on AUR VCS packages from other projects a good idea and who should decide on that? Upstream generally. If packages are tightly coupled (e.g. ring-* as far as I’m concerned, or Intel GPU toolchain), they will likely depend on
Le 16/04/2019 à 15:19, Lone_Wolf a écrit : the VCS version of the other packages. If not, then they should depend on the normal version, and people are free to try substituting the VCS version for any of them on their own (just like they are substituting the initial package with the VCS one).
I don’t know enough mesa/llvm to tell how tightly coupled they are, but I guess that if upstream asks this, then likely not so much. I also don’t know how different the mesa-git PKGBUILD would be then, but you can still maintain a local branch with the differences for your usecase.
Regards, Bruno
There are 2 types of problems. 1. runtime libraries mesa-git built against a specific llvm version needs the runtime libraries of that version. If those aren't present, user gets an error that doesn't mention llvm at all. You can verify this by doing these steps : - install mesa - pacman -Rdd llvm-libs - run glxinfo glxinfo will show complaints like libGL error: MESA-LOADER: failed to open radeonsi (search paths /usr/lib/dri) Nothing in the error messages points to the real cause : missing needed llvm run time libraries. 2. features/stability gotten don't match expectations People that install mesa trunk usually want something that's not present or fails with [extra]/mesa. In my experience many mesa trunk features/fixes require changes to llvm only present in trunk. this tends to be the most visible when llvm trunk is hundreds or thousands commits ahead of releases. A few years ago we had this situation : mesa-git & llvm-svn were maintained by the same person. mesa-git depended on llvm/llvm-libs. I maintained mesa-radeon-git and built against llvm-svn / llvm-libs-svn. Users of mesa-radeon-git (including myself) didn't have much problems. Users of mesa-git that build against repo llvm had a lot more problems. When that person stepped down as maintainer (fall of 2015) I took over mesa-git and Kerberizer took over llvm-svn. Kerberizer agreed with my assessment that mesa-git should be built against llvm-svn , not llvm. for almost 4 years mesa-git has been depending on llvm-svn with great success. If I were to adjust mesa-git to built against extra/llvm, I would add a conflict with llvm trunk. TL;DR : llvm trunk should be treated as a different version of llvm then the latest released version. Disclaimer: The above is based on my years of experience as user, builder and maintainer of mesa-git. If I am wrong, please show me proof. Lone_Wolf