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.
Lone_Wolf
