Can xbps-src work around runtime cyclic dependencies instead of requiring manually split templates?

[pullmoll]

We have a new cyclic dependency: pinentry -> gcr -> gnupg2 -> pinentry

The dependency is just a runtime dependency yet it prevents a bootstrapped arch (armv5tel here) from successfully breaking out of the cycle. Can we perhaps prevent runtime depends=… from creating such cycles?

[st3r4g]

I think xbps-src could be improved to handle such a scenario, which is not so uncommon. For example, libglvnd needs at least one GL vendor to work, but adding depends=mesa would introduce an endless loop at the moment.
One could detect the loop and break out of it, but it doesn't feel very elegant. Instead, what about making xbps-src build all the runtime dependencies after their "parent" package (i.e. the one that is being built)? I did a little experiment in this branch: https://github.com/st3r4g/void-packages/tree/xbps-src-rdeps
Obviously this is not feasible right now, as packages would be added to the index before some of their dependencies are built. But I believe this could work with a better staging mechanism, handled outside of xbps-rindex.
The current staging mechanism cannot handle multiple repositories, so it needs to be improved anyway. It was proposed something like: xbps-rindex always stages, a new tool (multirepo aware) checks for publishing the packages that are ready (shlibs and runtime deps checks).

[st3r4g]

build cycles should not be workarounded, they must not exist at all.

but it's not a real build cycle... building all dependencies (runtime too) first is probably simpler but not the best solution imho. My proposal seems simple enough, why is it bad? Splitting packages is also a not very elegant workaround, they must be kept in sync manually and such...

[st3r4g]

st3r4g@39916d1
commit msg means that this can only work if the staging mechanism is changed, as explained in comment above, but I think there are ideas in this direction already.

[Chocimier]

@st3r4g: When dependencies are build after desired package is indexed, and some transitive dependency fail to build, one end up with non-installable package and no easy way to build just what is missing. Currently, it is enough to fix failing package and build desired package again.

Complete solution may need a temporary area of packages visible to xbps-src, but not indexed yet.

[st3r4g]

@st3r4g: When dependencies are build after desired package is indexed, and some transitive dependency fail to build, one end up with non-installable package and no easy way to build just what is missing. Currently, it is enough to fix failing package and build desired package again.

Complete solution may need a temporary area of packages visible to xbps-src, but not indexed yet.

Exactly, the index must be updated only after all runtime dependencies are built successfully. In void-linux/xbps#259 (comment) a new tool was proposed to handle proper indexing of packages (in a multi-repo aware way). So if such tool is made, we can postpone building runtime deps and let the new tool do the shlibs checks and rundeps checks, so that repo index has always installable packages.

[ericonr]

Still an issue, have just renamed.