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

On 8/25/21 4:03 AM, Mario Finelli via aur-general wrote:

I've been debating with myself for a little while now on how to best to respond to this. On the one hand I totally get it that it's annoying to not be able to just `$helper -S package` and need to either manually edit the pkgbuild, or call --nocheck, or whatever. On the other hand running the test suite is extremely valuable to pick up breakage between both gem versions and ruby versions. Fortunately, for ruby packages the dependency cycle is usually only for checkdepends so once you've built and installed the package the first time upgrades should be smooth even with the check.

It's possible that this is actually only something that we care about for the official repositories and so I'm out of place by including them on these AUR packages. I admit that I haven't seen circular dependencies elsewhere on the AUR, but I also don't install that many packages so maybe they just exist on packages that I haven't seen or don't use.

Anyway, if the consensus (or even just some TU telling me to do it) is to get rid of the check() functions and checkdepends then I of course will comply -- I'll just be a little sad about it :)

I have also a few ruby-* packages in AUR and I'm aware that they also bring in cyclic check dependencies, especially in the ruby-rails world and their subpackages. I'm in general also a fan of having tests for packages since they do serve a purpose. But in my dealings with these packages I have an increasingly harder time to manage the cycles and keeping my local repo up-to-date. Especially when a new rails version comes out. If there is a consensus from this thread to avoid such cycles then I will be happy to update my packages and just comment out the check() related lines. That way if people want to run them later they can re-enable them when the inspect the PKGBUILD file (which they should do anyway during install). Best regards Segaja