Source: gnupg2,wine
Control: found -1 gnupg2/2.4.8-5
Control: found -1 wine/10.0~repack-12
Control: block 1124433 by -1
Severity: serious
Tags: forky sid
Justification: https://release.debian.org/testing/rc_policy.txt 6a
User: debian-ci@lists.debian.org
Usertags: breaks needs-update
User: debian-qa@lists.debian.org
Usertags: i386

(This is very similar to corresponding bugs that I opened for
src:libassuan + src:wine and src:libgpg-error + src:wine)

Since wine was updated to 10.0~repack-12, wine:i386 no longer provides
/usr/lib/wine/wine. Instead, it's now /usr/bin/wine or
/usr/lib/${DEB_HOST_MULTIARCH}/wine/wine. Similarly, the
wineserver is now /usr/lib/${DEB_HOST_MULTIARCH}/wine/wineserver.

This breaks assumptions made by the gpgv-win32 autopkgtest in gnupg2,
causing the new wine version to be unable to migrate to testing, which
in turn results in #1124433 not getting fixed in testing.

If this is an intentional interface change, then debian/tests/gpgv-win32
in src:gnupg2 will need updating to use more appropriate paths.

Even if this was an intentional interface change, it might be a good
idea to special-case wine:i386 to provide enough symlinks in
/usr/lib/wine/ that autopkgtests like this one will still pass: that
would allow this bug to be reassigned to src:gnupg2 at a lower severity,
and the compatibility symlinks could be removed when gnupg2 and other
affected packages (dxvk, libassuan, libgpg-error) have been updated.

Or, if this was not an intentional interface change, perhaps wine should
special-case wine:amd64 and wine:i386 to provide those symlinks in the
longer term?

I've usertagged this as both "breaks" and "needs-update" because it
isn't obvious to me whether changes are desired in gnupg2, in wine,
or both, but at least one of these two packages will need changes before
a version of wine with the new paths can migrate.

Thanks,
    smcv