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

[Bruno Pagani]

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