You are not logged in.

#1 2020-07-23 17:29:11

realh
Member
Registered: 2016-12-02
Posts: 13

Dynamic dependencies with optdepends

I want to make a feature in aur/roxterm-git optional at build time, but the feature relies on a modified API in the vte3 library it depends on, so I want to put the patched library in AUR too, but not force its use in roxterm-git. If the feature is enabled in roxterm-git at build-time, it is no longer compatible with the vanilla vte3 from extra. Can this be done with optdepends or by some other means without adding another variant of roxterm to AUR?

Specifically, the latest version of roxterm supports kinetic scrolling with libinput, but it needs a patched version of vte3. roxterm is written in C and its upstream build files automatically detect whether the currently installed vte has the new functions this feature requires. I want to add the patched vte to AUR as "vte3-kinetic", and make it provide (and conflict with) vte3, but not force roxterm users to use it. I suspect that optdepends is only meant for packages which can enable/disable optional features dynamically at run-time, not where the optional dependencies are baked in at build-time like this.

Seeing as PKGBUILD files are specialised build scripts it should be possible to do something like this:

if [detect patched vte3]; then
    vtevar=vte3-kinetic
else
    vtevar=vte3
fi
depends=($vtevar ...)

Is it OK to do that?

Offline

#2 2020-07-23 21:02:42

eschwartz
Fellow
Registered: 2014-08-08
Posts: 4,097

Re: Dynamic dependencies with optdepends

You could add a variable to the top of the PKGBUILD:

# set this to 1 to force vte-kinetic
_USE_PATCHED_VTE=

[...]

if [[ -n ${_USE_PATCHED_VTE} ]]; then
    depends+=('vte3-kinetic')
else
    depends+=('vte3')
fi

You could also key off of this to pass flags to the package that override the autodetection.

Essentially, a poor man's Gentoo USE flags.

...

Dynamically modified metadata tends to be frowned upon. This is one of the more innocent cases I've seen (there are people who do pkgver=$(curl https://api.github.com/repos/foo/bar/releases | jq ...) and we nuke that on sight for blatant abuse), but even so I'd be concerned that generating .SRCINFO on a system with vte3-kinetic would produce the wrong info...

Last edited by eschwartz (2020-07-23 21:05:43)


Managing AUR repos The Right Way -- aurpublish (now a standalone tool)

Offline

#3 2020-07-23 21:15:01

realh
Member
Registered: 2016-12-02
Posts: 13

Re: Dynamic dependencies with optdepends

Thanks for your input. The trouble with users having to edit PKGBUILD is that it makes it harder to enable the feature when using something like yay. How about if I don't clear the variable at the top of PKGBUILD (and rename it to something beginning with ROXTERM_ to reduce the possibility of a name clash)? Then users could simply set it before running yay etc.

Should .SRCINFO always contain the most generic of multiple choice dependencies (in this case always vte3, not vte3-kinetic) as a reference for the AUR as a whole, or should it reflect which was used for a local build? And in the former case, is there a way for PKGBUILD to detect that it's being used to generate .SRCINFO and force vte3-kinetic off?

Last edited by realh (2020-07-23 21:22:13)

Offline

#4 2020-07-24 08:37:43

Alad
Wiki Admin/IRC Op
From: Bagelstan
Registered: 2014-05-04
Posts: 2,407
Website

Re: Dynamic dependencies with optdepends

A much simpler solution is to not support broken AUR helpers. PKGBUILDs are meant to be run with makepkg, so that's the only sensible thing to support.


Mods are just community members who have the occasionally necessary option to move threads around and edit posts. -- Trilby

Offline

#5 2020-07-24 13:30:51

realh
Member
Registered: 2016-12-02
Posts: 13

Re: Dynamic dependencies with optdepends

This probably isn't the right place for it, but if you think yay should be avoided, please could you point me to an article or something about that? Because I find it very useful. And it doesn't really answer the question: is it OK to refer to an external variable in PKGBUILD?

Offline

#6 2020-07-24 13:42:36

progandy
Member
Registered: 2012-05-17
Posts: 5,184

Re: Dynamic dependencies with optdepends

Personally, I'd probably add it to the optdepends and add a note that roxterm has to be recompiled.

Another alternative would be to patch roxterm to use dlsym(RTLD_DEFAULT...) instead for that one function call.

Thanks for your input. The trouble with users having to edit PKGBUILD is that it makes it harder to enable the feature when using something like yay.

Most better AUR helpers should allow you to view&edit the PKGBUILD before the build.

Last edited by progandy (2020-07-24 13:51:52)


| alias CUTF='LANG=en_XX.UTF-8@POSIX ' |

Online

#7 2020-07-24 13:52:58

realh
Member
Registered: 2016-12-02
Posts: 13

Re: Dynamic dependencies with optdepends

progandy wrote:

Personally, I'd probably add it to the optdepends and add a note that roxterm has to be recompiled.

Another alternative would be to patch roxterm to use dlsym(RTLD_DEFAULT...) instead for that one function call.

I was reluctant to add the extra complexity at first, but you're right, I should load the function dynamically. It already has to be compiled with GModule flags anyway, to support GtkBuilder.

Offline

Board footer

Powered by FluxBB