[ISSUE] New cyclic dependency

[ISSUE] New cyclic dependency

[pullmoll]

[-- Attachment #1: Type: text/plain, Size: 417 bytes --]

New issue by pullmoll on void-packages repository

https://github.com/void-linux/void-packages/issues/20438

Description:
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?

Re: New cyclic dependency

[st3r4g]

[-- Attachment #1: Type: text/plain, Size: 1194 bytes --]

New comment by st3r4g on void-packages repository

https://github.com/void-linux/void-packages/issues/20438#issuecomment-605719104

Comment:
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).

Re: New cyclic dependency

[xtraeme]

[-- Attachment #1: Type: text/plain, Size: 299 bytes --]

New comment by xtraeme on void-packages repository

https://github.com/void-linux/void-packages/issues/20438#issuecomment-614098367

Comment:
A solution is to make a pinentry pkg that simply creates pinentry (main pkg, curses) and pinentry-tty. And then split the -qt and -gtk parts to another pkg.

Re: New cyclic dependency

[xtraeme]

[-- Attachment #1: Type: text/plain, Size: 164 bytes --]

New comment by xtraeme on void-packages repository

https://github.com/void-linux/void-packages/issues/20438#issuecomment-614102374

Comment:
I'll handle this one.

Re: New cyclic dependency

[xtraeme]

[-- Attachment #1: Type: text/plain, Size: 187 bytes --]

New comment by xtraeme on void-packages repository

https://github.com/void-linux/void-packages/issues/20438#issuecomment-614113628

Comment:
Note that #20508 does not help in this case!

Re: New cyclic dependency

[xtraeme]

[-- Attachment #1: Type: text/plain, Size: 335 bytes --]

New comment by xtraeme on void-packages repository

https://github.com/void-linux/void-packages/issues/20438#issuecomment-614115109

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

Other build systems are full of stupid workarounds just for this. I refuse to introduce stuff like this into xbps-src.

Re: [ISSUE] [CLOSED] New cyclic dependency

[xtraeme]

[-- Attachment #1: Type: text/plain, Size: 420 bytes --]

Closed issue by pullmoll on void-packages repository

https://github.com/void-linux/void-packages/issues/20438

Description:
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?

Re: New cyclic dependency

[st3r4g]

[-- Attachment #1: Type: text/plain, Size: 427 bytes --]

New comment by st3r4g on void-packages repository

https://github.com/void-linux/void-packages/issues/20438#issuecomment-614235658

Comment:
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...

Re: New cyclic dependency

[st3r4g]

[-- Attachment #1: Type: text/plain, Size: 501 bytes --]

New comment by st3r4g on void-packages repository

https://github.com/void-linux/void-packages/issues/20438#issuecomment-614235658

Comment:
> 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...

Re: New cyclic dependency

[xtraeme]

[-- Attachment #1: Type: text/plain, Size: 189 bytes --]

New comment by xtraeme on void-packages repository

https://github.com/void-linux/void-packages/issues/20438#issuecomment-614239090

Comment:
@st3r4g I can't comment unless I see the code.

Re: New cyclic dependency

[st3r4g]

[-- Attachment #1: Type: text/plain, Size: 229 bytes --]

New comment by st3r4g on void-packages repository

https://github.com/void-linux/void-packages/issues/20438#issuecomment-614239649

Comment:
https://github.com/st3r4g/void-packages/commit/415b1820205ce7f38744ae81a68eb06a65ce5858

Re: New cyclic dependency

[st3r4g]

[-- Attachment #1: Type: text/plain, Size: 337 bytes --]

New comment by st3r4g on void-packages repository

https://github.com/void-linux/void-packages/issues/20438#issuecomment-614239649

Comment:
https://github.com/st3r4g/void-packages/commit/415b1820205ce7f38744ae81a68eb06a65ce5858
commit name means that this only works if the staging mechanism is changed, as explained in comment above.

Re: New cyclic dependency

[st3r4g]

[-- Attachment #1: Type: text/plain, Size: 340 bytes --]

New comment by st3r4g on void-packages repository

https://github.com/void-linux/void-packages/issues/20438#issuecomment-614239649

Comment:
https://github.com/st3r4g/void-packages/commit/415b1820205ce7f38744ae81a68eb06a65ce5858
commit name means that this can only work if the staging mechanism is changed, as explained in comment above.

Re: New cyclic dependency

[st3r4g]

[-- Attachment #1: Type: text/plain, Size: 387 bytes --]

New comment by st3r4g on void-packages repository

https://github.com/void-linux/void-packages/issues/20438#issuecomment-614239649

Comment:
https://github.com/st3r4g/void-packages/commit/415b1820205ce7f38744ae81a68eb06a65ce5858
commit name means that this can only work if the staging mechanism is changed, as explained in comment above, and I think there are steps in this direction.

Re: New cyclic dependency

[st3r4g]

[-- Attachment #1: Type: text/plain, Size: 386 bytes --]

New comment by st3r4g on void-packages repository

https://github.com/void-linux/void-packages/issues/20438#issuecomment-614239649

Comment:
https://github.com/st3r4g/void-packages/commit/415b1820205ce7f38744ae81a68eb06a65ce5858
commit msg means that this can only work if the staging mechanism is changed, as explained in comment above, and I think there are steps in this direction.

Re: New cyclic dependency

[st3r4g]

[-- Attachment #1: Type: text/plain, Size: 394 bytes --]

New comment by st3r4g on void-packages repository

https://github.com/void-linux/void-packages/issues/20438#issuecomment-614239649

Comment:
https://github.com/st3r4g/void-packages/commit/415b1820205ce7f38744ae81a68eb06a65ce5858
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.

Re: New cyclic dependency

[xtraeme]

[-- Attachment #1: Type: text/plain, Size: 296 bytes --]

New comment by xtraeme on void-packages repository

https://github.com/void-linux/void-packages/issues/20438#issuecomment-614250367

Comment:
hmm just looked into it, seems a good idea after all!

so what your code does is just deferring building runtime deps until the pkg is built, isn't it?

Re: New cyclic dependency

[xtraeme]

[-- Attachment #1: Type: text/plain, Size: 186 bytes --]

New comment by xtraeme on void-packages repository

https://github.com/void-linux/void-packages/issues/20438#issuecomment-614250840

Comment:
@st3r4g but I'm not sure if this is enough.

Re: New cyclic dependency

[Chocimier]

[-- Attachment #1: Type: text/plain, Size: 529 bytes --]

New comment by Chocimier on void-packages repository

https://github.com/void-linux/void-packages/issues/20438#issuecomment-615333740

Comment:
@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.

Re: New cyclic dependency

[st3r4g]

[-- Attachment #1: Type: text/plain, Size: 947 bytes --]

New comment by st3r4g on void-packages repository

https://github.com/void-linux/void-packages/issues/20438#issuecomment-615345691

Comment:
> @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 https://github.com/void-linux/xbps/issues/259 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.

Re: New cyclic dependency

[st3r4g]

[-- Attachment #1: Type: text/plain, Size: 970 bytes --]

New comment by st3r4g on void-packages repository

https://github.com/void-linux/void-packages/issues/20438#issuecomment-615345691

Comment:
> @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 https://github.com/void-linux/xbps/issues/259#issuecomment-608367884 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.

Re: New cyclic dependency

[st3r4g]

[-- Attachment #1: Type: text/plain, Size: 394 bytes --]

New comment by st3r4g on void-packages repository

https://github.com/void-linux/void-packages/issues/20438#issuecomment-614239649

Comment:
https://github.com/st3r4g/void-packages/commit/39916d1b7acaaa225b881127ff6d8abaf037366a
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.

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

[ericonr]

[-- Attachment #1: Type: text/plain, Size: 177 bytes --]

New comment by ericonr on void-packages repository

https://github.com/void-linux/void-packages/issues/20438#issuecomment-773763767

Comment:
Still an issue, have just renamed.