[aur-general] Cycled dependencies in AUR

[Caleb Maclennan]

On 2021-08-24 19:11, Hugo Osvaldo Barrera via aur-general wrote:
> On Tue, 24 Aug 2021, at 15:12, Mikhail f. Shiryaev via aur-general 
> wrote:
>> The same is valid for package ruby-rubocop-performance [6] that is
>> dependency for rubocop check and requires it to be built
> 
> There's not really much that can be done to work around this, since
> the dependency also exists upstream. Potentially, AUR helpers can
> detect these scenarios and do a first pass with `--nocheck`, and then
> a second rebuild.

I don't know of *any* that do that yet, and even instructing users to do 
this by hand is difficult. As a *packager* building packages for my own 
package repo it takes quite a bit of brain power and trial/error to sort 
out what order to build. I tihnk I'd have to agree with Mikail here that 
this is leaves room for improvement, and AUR packages should make 
concessions for this.

> Note that this isn't the only instance of a circular dependency like 
> this.
> Another known similar situation is rust, which requires rust to be
> built [1]. Again,the package only reflects upstream's situation.

There are lots of other instances of this, but I'm not sure Rust is 
really the same. Rust has a bootstrap issue with *building* itself, but 
that is ⓐ not an issue for end users because a binary package for it 
exists in the repos and the bother of bootstrapping it is on packagers, 
and ⓑ is not at all the same as a test suite that introduces a circular 
loop.

Incidentally I just rehashed one of these in Python the other day 
(again). The upstream projects in the Python font tooling world 
regularly assume their test suites are run with Tox and/or something 
that can just `pip` out for a wheel of whatever they need to run. There 
are at least 3 different loops over about 15 packages.

My solution to the loop I was dealing with (besides opening an upstream 
bug report[1]) was to look around the circular loop for where something 
was only a *checkdepends* and disable the checks by default for that 
package. This is less than ideal too, but I think it's better than piles 
of users frustrated because they can't able to build anything and 
otherwise fully functional packages claiming they aren't able to satisfy 
dependencies.

I experimented with adding code to leave the tests but keep them from 
running, such as adding this:

BUILDENV+=(!check)

This works for local builds with `makepkg` but it doesn't work for 
chroot builds and it doesn't work for most AUR helpers. Frustratingly 
the `options=()` field can't touch this either. I suppose I could get 
more aggressive with a custom env var check to inject the check deps and 
function if found so at least I as the packages maintainer can build it 
with checks, but that feels ugly.

I too feel like there should be a better way to handle this. I don't 
know what it is.

Caleb

[1] https://github.com/typemytype/booleanOperations/issues/64