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