[Solved]AUR helpers & dynamic variables

Lone_Wolf · 2020-03-29 16:02:12

Something I should have asked long ago but didn't .

In some of my aur packages I use dynamic variables/functions that are set during buildtime .
An example is the aur llvm-git package .

It uses _ocamlver() to determine the actual installed version of ocaml .
This value is then used in package_llvm-ocaml-git() to ensure the correct ocaml version is present when llvm-ocaml-git is installed .

Before uploading to AUR we have to create an uptodate .SRCINFO file, this file contains the current value of ocaml .
Let's say the value is 9.0 .

Possible Scenario
User Z builds & installs llvm-git and sub-packages
time passes
Ocaml is updated to version 9.0.1
Z runs pacman -Syu and gets a message wrt a conflict between ocaml 9.0.1 and llvm-ocaml-git .

User Z understands they need to maintain aur packages themselves and removes llvm-git temporarily .
pacman -Syu succeeds, Z starts rebuilding llvm-git .

- Branch A
Z uses makepkg or devtools, build succeeds and new version of llvm-git is installed.
<the end>

- Branch B
Z uses an aur helper.

Aur helper doesn't source the PKGBUILD but uses .SRCINFO to determine dependencies.
.SRCINFO still contains the old version 9.0 and the Aur helper tries to use that.
This fails and the aur helper shows a message ocaml 9.0 is needed and complains.

User Z doesn't understand what is happening and complains also.

Best solution would ofcourse be to go back to A and build with makepkg / devtools, but user Z wants to keep using their aur helper.

A workaround would be for Z to run makepkg --printsrcinfo > .SRCINFO so the information in .SRCINFO is updated to the actual values.
This makes the aur helper happy and llvm-git is updated.
<the end>

Is it a good idea to advise users of aur helpers to update .SRCINFO before building such packages or are their downsides to that ?

[SOLUTION]

Dynamic variables in PKGBUILDs should only be used if there's no other choice.
Check the problem definition carefully and think very hard about other solutions.

Last edited by Lone_Wolf (2020-04-01 11:07:57)

Trilby · 2020-03-29 16:27:57

Lone_Wolf wrote:

Is it a good idea to advise users of aur helpers to update .SRCINFO before building such packages or are their downsides to that?

No. If the materials provided in the AUR need to be updated, it's your job to do so and bump the pkgrel. Whether people use helpers or not is irrelevant. More importantly:

Lone_Wolf wrote:

In some of my aur packages I use dynamic variables/functions that are set during buildtime.

Don't do that. Problem solved.

Side note / pet peeve: awk piped to cut piped to cut is ridiculous. Awk or sed are more than capable of acheiving your goal there.

eschwartz · 2020-03-29 23:08:25

Having the user run makepkg --printsrcinfo > .SRCINFO wouldn't actually help, since they might not even have ocaml installed, and then you would end up with:

depends=("ocaml=")

And that just plain won't work.

This will sometimes work by accident, since users who have previously installed the package will often have ocaml already installed because they may not have removed the -ocaml-git split package which most users don't need.

Lone_Wolf · 2020-03-30 12:49:11

The _ocamlver() code was written long ago by someone. I don't understand how it works, but it does achieve its purpose.

It does use the repo version of ocaml when there's no local ocaml instllation.
Whether makepkg --printsrcinfo does run that function is unknown to me, but seems unimportant.

The responses made me realise I should focus on what I want to achieve.

In order for ocaml bindings to work with llvm , the exact same version of ocaml used to build llvm against needs to be present at runtime.
This also works in reverse : when a new ocaml version is available, it could require changes in llvm.
Having to change the static value manually is an excellent trigger to check for that.

In the llvm / ocaml usecase using a dynamic variable is a bad idea.

Last edited by Lone_Wolf (2020-03-30 12:50:03)

Trilby · 2020-03-30 13:02:15

Lone_Wolf wrote:

In order for ocaml bindings to work with llvm , the exact same version of ocaml used to build llvm against needs to be present at runtime.

There is nothing remotely unique about this situation. A wide range of AUR packages have library dependencies and require the exact same library be present at runtime as when the package was built. All require an ABI-compatible version, and with some libs there is little to no ABI compatibility between subsequent versions. When the dependency is updated, the user will simply get an error message saying a required library couldn't be found - and they'll realize they need to rebuild the AUR package. Again, nothing remotely uncommon about this situation.

Just ditch all the versioned dependencies all together. You are creating excess work for yourself, and for the user's of your package.

No other package that I'm aware of specifies versioned dependencies when the version-dependence only exists because thats the version the binary was built against. Versioned dependencies are for when a program could only be built against specific versions and would fail to build with others. It is generally assumed that once built, it depends on what it was built against.

So not only is a dynamic variable a bad idea, any variable at all specifying the version is a bad idea. Your package depends on ocaml, leave it at that.

Last edited by Trilby (2020-03-30 13:05:06)

Lone_Wolf · 2020-04-01 11:03:21

Thanks for the input, package cleaned up.

Arch Linux

#1 2020-03-29 16:02:12

[Solved]AUR helpers & dynamic variables

#2 2020-03-29 16:27:57

Re: [Solved]AUR helpers & dynamic variables

#3 2020-03-29 23:08:25

Re: [Solved]AUR helpers & dynamic variables

#4 2020-03-30 12:49:11

Re: [Solved]AUR helpers & dynamic variables

#5 2020-03-30 13:02:15

Re: [Solved]AUR helpers & dynamic variables

#6 2020-04-01 11:03:21

Re: [Solved]AUR helpers & dynamic variables

Board footer