[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 03/05/2019 à 16:04, Eli Schwartz via aur-general a écrit :
> On 5/1/19 10:53 AM, Doug Newgard via aur-general wrote:
>> On Wed, 1 May 2019 12:38:41 +0200
>> Lone_Wolf <lonewolf at xs4all.nl> wrote:
>>> Assumptions :
>>>
>>> mesa-git depends on llvm and llvm-libs
>>>
>>> AUR only has one mesa-git package
>>>
>>> User builds in clean chroot with devtools
>>>
>>> User wants mesa feature X, finds they need to run mesa-git for that.
>>>
>>>
>>> User clones aur mesa-git and builds with extra-x86_64-build
>>>
>>> makepkg sees llvm / llvm-libs dependencies are satisfied by extra/llvm 
>>> and extra/llvm-libs.
>>>
>>> mesa-git is build against those versions
>>>
>>> user installs mesa-git, pacman sees llvm-libs is needed and finds 
>>> extra/llvm-libs installed.
>>>
>>>
>>> User runs mesa-git, realizes feature X is not working.
>>>
>>> Investigation reveals feature X is not supported by stable llvm, user 
>>> needs to built mesa-git against llvm-git.
>>>
>>> User builds llvm-git + llvm-libs-git in clean chroot.
>>>
>>> In order to use the llvm-git for mesa-git building they add the packages 
>>> manually to extra-x86_64-build.
>>>
>>> They now have a mesa-git build against llvm-git and install that.
>>>
>>> pacman sees mesa-git depends on llvm-libs , and that's satisfied by 
>>> extra/llvm-libs.
>>>
>>> user tries again , mesa-git crashes.
>>>
>>>
>>> User asks for help on forum.
>>>
>>> Someone that understands how mesa and llvm interact, suggests they try 
>>> installing llvm-libs-git .
>>>
>>> User installs that, mesa-git works and feature X also works .
>>>
>>> User is happy, tries to figure out how to avoid similar issues in future.
>>>
>>>
>>> Someone points out that the mesa-git crash was caused by pacman being 
>>> unaware which llvm-libs binary version was needed.
>>>
>>> Simple solution : edit depends in PKGBUILD to have mesa-git depend on 
>>> llvm-git / llvm-libs-git .
>> Full stop. Solution is not to edit the PKGBUILD, solution is for the
>> theoretical user to not be replacing system libraries when they don't have a
>> clue what they're doing.
>>
>> You're trying to overcomplicate the system to account for user stupidity. This
>> is Arch, stop doing that.
> I'm still not really seeing what the problem here is.
>
> Lone Wolf's point here, is that mesa-git results in different codegen
> and different features, if the build-time compilation environment is
> llvm-git.

Yes, so say so in a pinned comment and be done with it.

> It's not unreasonable to want the resulting package to have technically
> correct dependency linkages when its compilation environment results in
> *different dependencies*.

It’s user choice to use llvm-git instead of llvm. They are free to edit
the PKGBUILD to get correct dependencies listed on their system if they
want. But they are tons of software where building against the dev
version of a dependency binds you to it (or requires a recompilation to
switch back to the non-dev version). Just think of any software where
the soname bumped between release and current trunk for instance. Would
you advocate a specific PKGBUILD for all possible cases?

> Furthermore, if one would host the resulting package in a prebuilt
> binary repository, I defy the idea that users failing to realize they
> need llvm-git specifically, is "user stupidity".

Although this one is a good point, I would then say that the person
handling the binary repository should switch the dependency to llvm-git
before building. If they go the way of publishing a package, they can
afford a `sed` in their publication toolchain. And they should also
provide a matching binary llvm-git, because I expect the dep to be the
exact same as the makedep in this case, since a newer llvm-git than
build-time one could break things, just like llvm-git does w.r.t. llvm
from the repos.

> Furthermore, I defy the idea that even users building it themselves
> constitute "user stupidity", because as Lone Wolf's explanation
> *explicitly* called out, it is awkward in the extreme to kludge around
> adding a *build-time* codegen dependency on llvm-git, inside a
> makechrootpkg compilation environment... without actually doing so via
> makepkg's "makedepends" technology.

I did not understood that paragraph.

Bruno