Bug#1125096: RM: libglib2.0-0 [amd64 armhf i386] -- NBS; blocking piuparts (#1111475)

[Simon McVittie]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: glib2.0 at packages.debian.org
Control: affects -1 + src:glib2.0
User: ftp.debian.org at packages.debian.org
Usertags: remove
Control: block 1111475 by -1

src:glib2.0 has a cruft package libglib2.0-0 in unstable on amd64, armhf 
and i386:

$ rmadison -s unstable -S glib2.0 | grep -F -v ' 2.86.3-4 '
glib2.0                     | 2.78.4-1      | unstable   | source
glib2.0                     | 2.78.4-6      | unstable   | source
libglib2.0-0                | 2.78.4-1      | unstable   | armhf
libglib2.0-0                | 2.78.4-6      | unstable   | amd64, i386
libglib2.0-data             | 2.78.4-1      | unstable   | all
libglib2.0-data             | 2.78.4-6      | unstable   | all
libglib2.0-doc              | 2.78.4-1      | unstable   | all
libglib2.0-doc              | 2.78.4-6      | unstable   | all

The existence of cruft in unstable confuses piuparts (#1123031) causing 
new glib2.0 versions to be unable to migrate without release team 
intervention (#1111475).

Please remove libglib2.0-0, leaving its functionality to be provided by 
libglib2.0-0t64.

dak says there is a dependency problem on armhf and i386 (but not amd64):

smcv at coccia ~ % dak rm -R -n -b libglib2.0-0
...
# Broken Depends:
xpra: xpra [armhf i386]

so that package might need to either be removed from armhf and i386, or 
be left intentionally uninstallable on armhf, to be able to do this. (It 
would still be installable on i386 because on i386, the t64 transition 
didn't change the ABI, therefore libglib2.0-0t64 still Provides 
libglib2.0-0.)

xpra is RC-buggy (#1067627, #1072463, #1086122, #1101929) and was most 
recently built successfully on the affected architectures in 2023, so I 
don't feel particularly bad about regressing it further.

Thanks,
    smcv