[aur-general] Cycled dependencies in AUR

[Mikhail f. Shiryaev]

On Wed, Aug 25, 2021 at 9:55 AM Andreas 'Segaja' Schleifer via aur-general <
aur-general at lists.archlinux.org> wrote:

> 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
>

Thank you for your clarification everybody. I got the reasons behind the
decision and they make sense, for sure!

Regards,
Mikhail