[aur-general] Are AUR VCS packages that depend on AUR VCS packages from other projects a good idea and who should decide on that ?

[Lone_Wolf]

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