Some 32bit packages don't have the deps correctly rewritten to -32bit packages

Johnnynator commented 4 years ago

System

xuname:
output of xuname (part of xtools)
package:
affected package(s) including the version: xbps-query -p pkgver <pkgname>

Expected behavior

E.g. qt5-concurrent-32bit-5.15.0_1 should depend on qt5-core-32bit-5.15.0_1 not qt5-core-5.15.0_1

Actual behavior

xbps-query -R qt5-concurrent-32bit -p run_depends
qt5-core-5.15.0_1
libstdc++-32bit>=4.4.0_1
libgcc-32bit>=4.4.0_1
glibc-32bit>=2.29_1

Steps to reproduce the behavior

(Mainly just as a reminder for myself)

ericonr commented 4 years ago

You can close #5194 to track it only here if you want.

dmarto commented 3 years ago

I don't know the status of the issue (as it is a bit old), I am just passing to report 2 such packages

`pango-devel-32bit`

makedepends="fribidi-devel harfbuzz-devel libXft-devel libthai-devel"
depends="${makedepends} pango-xft>=${version}_${revision} pango>=${version}_${revision}"

All, but pango itself, are not rewritten to the 32bit versions.

`eudev-libudev-devel-32bit`

eudev-libudev-devel-32bit is depending on eudev-libudev and eudev-libudev-devel

I find the latter dependency extra strange, and that threw me in a circle that led to the edits of my comment.

--

As usual, I am happy to help in any way, if I get a pointer or two (pun slightly intended) I am willing to go dig inside xbps to try and fix that.

ericonr commented 3 years ago

I think @Chocimier was looking into this.

I don't particularly like the -devel-32bit packages, and would recommend compiling on a i686 chroot instead.

ericonr commented 3 years ago

(but since we generate them, they should actually work)

Chocimier commented 3 years ago

qt5-concurrent-32bit bug occurs because pre-pkg/05-prepare-32bit.sh reads shlib-provides file generated by pre-pkg/06-shlib-provides.sh, thus subpackages processed earlier will never be rewritten to depend on -32bit versions of subpackages processed later.

Splitting pre-pkg phase to two phases, first with 06-shlib-provides.sh collect_sonames ${PKGDESTDIR}, and second with 05-prepare-32bit.sh, 06-shlib-provides.sh collect_sonames ${_destdir32} would be needed. Replacing 32bit packages with multilib prefixes might be better alternative.

On pango: when rebuild, depends looks fine, despite of no relevant changes done recently. The thing I did was about whether -devel-32bit packages are generated, but didn't changed rewriting of deps.

pkgver: pango-devel-32bit-1.48.9_1
run_depends:
        fribidi-devel-32bit>=0
        harfbuzz-devel-32bit>=0
        libXft-devel-32bit>=0
        libthai-devel-32bit>=0
        pango-xft>=1.48.9_1
        pango-32bit>=1.48.9_1

pkgver: eudev-libudev-devel-32bit-3.2.10_1
run_depends:
        eudev-libudev>=3.2.10_1

github-actions[bot] commented 2 years ago

Issues become stale 90 days after last activity and are closed 14 days after that. If this issue is still relevant bump it or assign it.

github-actions[bot] commented 2 years ago

Issues become stale 90 days after last activity and are closed 14 days after that. If this issue is still relevant bump it or assign it.

void-linux / void-packages