[aur-general] Cycled dependencies in AUR
caleb at alerque.com
Tue Aug 24 17:45:04 UTC 2021
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
>> The same is valid for package ruby-rubocop-performance  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
> Another known similar situation is rust, which requires rust to be
> built . 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
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) 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
I experimented with adding code to leave the tests but keep them from
running, such as adding this:
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.
More information about the aur-general