dynamically set deps/makedeps are problem for aur helpers

Lone_Wolf · 2019-05-30 19:09:29

Mesa needs llvm.
In my aur mesa-git & aur lib32-mesa-git I have code that allows the user to choose one of 4 llvm variants against which mesa is build by setting an enviornmnet var, MESA_WHICH_LLVM .
(code snippet further down).

When I run makepkg --prtsrcinfo to create a fresh .SRCINFO , makepkg uses the value for MESA_WHICH_LLVM (typically 1 ) on my system and puts
the associated dep/makedep in .SRCINFO .
I upload latest PKGBUILD & SRCINFO to aur and aur webinterface shows those deps as they were when srcinfo was created.

Now a user downloads snapshot or git clones latest version and tries to build.

If they use makepkg, the value for MESA_WHICH_LLVM on their system is used and everything works.
Devtools also have no problem building.

AUR helpers however seem to rely on SRCINFO to determine dependencies and build those that aren't present first.
That means they won't use my code to determine what to build for this user.

Personally I dislike AYUR helpers and my first reaction was : if it works with makepkg and not with aur helpers, that's not my problem.

However in this specific case it seems to me I've discovered a hidden assumption in printsrcinfo / SRCINFO :
The information in it is static and doesn't change after creation .

printsrcinfo is a makepkg option and SRCINFO is used by aur helpers AND aur web-interface.
How could this be solved and where should a bug/feature report be created ?

Lone_Wolf

# MESA_WHICH_LLVM is an environment variable used to determine which llvm package tree is used to built mesa-git against.
# Adding a line to makepkg.conf that sets this value is the simplest way to ensure a specific choice.
#
# 1: llvm-minimal-git (aur) preferred value
# 2: llvm-git (aur)
# 3  llvm-svn (lordheavy unofficial repo)
# 4  llvm (stable from extra) Default value
# 
if [[ ! $MESA_WHICH_LLVM ]] ; then
    MESA_WHICH_LLVM=4
fi

case $MESA_WHICH_LLVM in
    1)
        # aur lone_wolf-llvm-git
        makedepends+=('llvm-minimal-git')
        depends+=('llvm-libs-minimal-git')
        ;;
    2)
        # aur llvm-git
        makedepends+=('llvm-git')
        depends+=('llvm-libs-git')
        ;;
    3)
        # mesa-git/llvm-svn (lordheavy unofficial repo)
        makedepends+=('llvm-svn' 'clang-svn')
        depends+=('llvm-libs-svn')
        ;;
    4)
        # extra/llvm
        makedepends+=(llvm=8.0.0 clang=8.0.0)
        depends+=(llvm-libs=8.0.0)
        ;;
    *)
esac

Trilby · 2019-05-30 21:56:54

Lone_Wolf wrote:

However in this specific case it seems to me I've discovered a hidden assumption in printsrcinfo / SRCINFO :
The information in it is static and doesn't change after creation .

What does this mean? I just retrieved the AUR source files, and ran `makepkg --printsrcinfo` and it worked fine. The original .SRCINFO downloaded listed the llvm-minimal-git dependencies from your system, and the output of printsrcinfo excluded those but included the default llvm and llvm-libs.

Really though the whole thing seems bass akwards. All those llvm alternatives should provide llvm, right? So your PKGBUILD should only list 'llvm' and 'llvm-libs' as dependencies. If any given user has something else on their system that provide those dependencies, good for them - that's all fine with makepkg (and with every AUR helper I'm aware of). I'd say get rid of that case block and all that environment variable stuff. Just depend on llvm/llvm-libs and be done with it.

Last edited by Trilby (2019-05-30 22:01:10)

Scimmia · 2019-05-30 22:58:56

Trilby wrote:

Really though the whole thing seems bass akwards. All those llvm alternatives should provide llvm, right? So your PKGBUILD should only list 'llvm' and 'llvm-libs' as dependencies. If any given user has something else on their system that provide those dependencies, good for them - that's all fine with makepkg (and with every AUR helper I'm aware of). I'd say get rid of that case block and all that environment variable stuff. Just depend on llvm/llvm-libs and be done with it.

You're talking to the wall. We've tried to tell him this before, but he refuses to accept it.

Lone_Wolf · 2019-05-31 10:10:01

There is a real issue with printsrcinfo.
Please accept the code in mesa-git /lib32-mesa-git as proof-of-concept[1] and keep this thread about the printsrcinfo issue.

What does this mean? I just retrieved the AUR source files, and ran `makepkg --printsrcinfo` and it worked fine. The original .SRCINFO downloaded listed the llvm-minimal-git dependencies from your system, and the output of printsrcinfo excluded those but included the default llvm and llvm-libs.

That demonstrates printsrcinfo output for this package depends on the state of the MESA_WHICH_LLVM environment variable at the time it is run.
On your system it's not set, so the PKGBUILD uses the default values for deps/makedeps .

makepkg and devtools source/execute the PKGBUILD and work as intended : users that want to use llvm trunk versions need to set an env var.
AUR helpers and AUR webinterface rely on .SRCINFO as populated by printsrcinfo and choke on this.

-------------------------------------
[1]
If you're interested in pros & cons of the underlying issues, check
http://archlinux.2023198.n4.nabble.com/ … 22635.html

Note : that link shows a read-only version of the thread.
If you want to respond, reply to the aur-general Mailing list, info at https://lists.archlinux.org/listinfo/aur-general

Trilby · 2019-05-31 11:24:44

Lone_Wolf wrote:

That demonstrates printsrcinfo output for this package depends on the state of the MESA_WHICH_LLVM environment variable at the time it is run.

Yup. That was my point. It looks like it's working fine. But it seems you are claiming this is precisely what printsrcinfo is doing wrong. Yet here we are, both agreeing that it does it right.

Lone_Wolf wrote:

On your system it's not set, so the PKGBUILD uses the default values for deps/makedeps.

Yup. Again, that's the point: it works fine.

Lone_Wolf wrote:

There is a real issue with printsrcinfo.

Huh? Where? You keep saying this, but you have yet to show any problem at all.

Lone_Wolf wrote:

Please accept the code in mesa-git /lib32-mesa-git as proof-of-concept

Proof of what concept? There are two problems with this: 1) you are doing it wrong, so even if something failed due to you doing it wrong, it would not be evidence of a "real issue with printsrcinfo", and 2) even though you are doing it wrong, printsrcinfo is still working just fine.

What's the actual problem here? That some AUR helpers rely on stale information and try to install the wrong dependencies in some cases? If so, that's the AUR helper's problem.

Again, I don't think your case statement is necessary or appropriate. But even with it in place, printsrcinfo still works fine.

As to the completely off-topic mailing list thread:

Lone_Wolf wrote:

Adjusting the mesa-git PKGBUILD to use repo llvm/clang would force me to
either change my workflow or maintain a package I don't use in that form.

This seems to be the crux of your argument - but it is a completely faulty premise. Your workflow would not need to change one bit as you already have llvm-some-special-version-git installed on your system and that package provides llvm. This is precisely why the 'provides' mechanism exists, so users can opt for other implementations of a dependency.

EDIT: I've just read all the way through the mailing list thread. And the one sound bit of reasoning there is the point on building this package for an unofficial repo. However, even that doesn't go nearly as far as it is afforded in that thread: if you build your own mesa-some-special-version-git and provide it in an onofficial repo, and you build it such that it depends on llvm-some-special-version-git then of course you would also provide llvm-some-special-version-git in that same repo. To not do this would be absurd. So if those packages are both in that repo, then the special version of llvm would satisfy the llvm dependency of the special version of mesa. Nothing more needed.

Even those who support your approach in that thread (e.g. eschwartz) are doing so in a context in which you yourself said that all the environment variable nonsese was "out the window" but here it is anyways. If you make a special version of mesa that depends specifically on a special version of llvm, that you'd be fine. I'd advocate for just dependening on llvm, but depending on a specific aur-version of llvm is not "wrong". It's this environment variable acrobatics that makes it "wrong".

FWIW, I initially balked and Scimmia's response here which seemed unwarranted. My impression has always been that you are a good community member who knows arch well and discusses arch-issues rationally. I do see why Scimmia feels this way now though. I'd still like to hope it is a misunderstanding or miscommunication of some of early premises that lead you down this line of thinking: for example, your workflow should not have to change if you do things properly - this seems a form of XY problem. Rather than butting heads on whether 'Y' is the right thing to do, it'd be more productive to go back to 'X' and address what lead you down the path to where 'Y' seemed necessary. So if you're open to going back to the drawing board and finding the best way to provide this package, I think much could be acheived here. But if you stick to your assertion that your PKGBUILD is a valid proof of concept (of something) that demonstrates some unspecified bug in printsrcinfo, then - in that case - I'll refrain from engaging here further as that conversation could go no where pleasant.

Last edited by Trilby (2019-05-31 12:06:25)

Arch Linux

#1 2019-05-30 19:09:29

dynamically set deps/makedeps are problem for aur helpers

#2 2019-05-30 21:56:54

Re: dynamically set deps/makedeps are problem for aur helpers

#3 2019-05-30 22:58:56

Re: dynamically set deps/makedeps are problem for aur helpers

#4 2019-05-31 10:10:01

Re: dynamically set deps/makedeps are problem for aur helpers

#5 2019-05-31 11:24:44

Re: dynamically set deps/makedeps are problem for aur helpers

Board footer