Le 16/04/2019 à 18:01, Lone_Wolf a écrit : > 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, >> >> Le 16/04/2019 à 15:19, Lone_Wolf a écrit : >>> 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 >> 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.
Can you show me the diff that you would have between a PKGBUILD compiling against llvm-svn and one compiling against llvm? I need this to assess what to do in this situation. Regards, Bruno
