On Tue, 24 Aug 2021, at 15:12, Mikhail f. Shiryaev via aur-general wrote: > Hello. > > Today I tried to build ruby-rubocop [1] package and it's in a strange > state. A lot of packages for the package are cross-dependent for the check, > for example ruby-ruby-progressbar [2] and ruby-fuubar [3]. The proposal of > how to solve it from Mario [4] is to skip the check() phase, see comment > [5]. > > The same is valid for package ruby-rubocop-performance [6] that is > dependency for rubocop check and requires it to be built > > IMHO the state when the packages aren't able to be built by the simple AUR > helper command like `yay -S ruby-rubocop` should be considered as room for > improvement. > > If I'm wrong, please say so. But I'd like to have AUR packages in an easily > installable state and not passing additional arguments like `--nocheck` for > makepackage commands. > > [1] - https://aur.archlinux.org/packages/ruby-rubocop > [2] - https://aur.archlinux.org/packages/ruby-ruby-progressbar/ > [3] - https://aur.archlinux.org/packages/ruby-fuubar/ > [4] - https://aur.archlinux.org/account/supermario > [5] - https://aur.archlinux.org/packages/ruby-rubocop-rspec/#comment-823420 > [6] - https://aur.archlinux.org/packages/ruby-rubocop-performance/ > > Best regards, > Mikhail f. Shiryaev > > p.s. Mario, sorry for sending you two messages. > > > >
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. 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. BTW: You might also be interested in quarry[2]. [1]: https://archlinux.org/packages/extra/x86_64/rust/ [2]: https://wiki.archlinux.org/title/Ruby#Quarry -- Hugo Osvaldo Barrera
