[pkg-gnupg-maint] Bug#1127144: gnupg2: autopkgtest regression on i386 with wine/10.0~repack-12

[Simon McVittie]

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 at lists.debian.org
Usertags: breaks needs-update
User: debian-qa at 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