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
