Base 1.28.1 API/ABI break?

[Yavor Doganov]

While reviewing the diff between 1.28.0 and 1.28.1 I noticed changes
to the ivar layout of GSTLS, NSPort and some other class I can't
remember right now.  Granted, these are unlikely to be subclassed, so
I thought we could sneak this in Debian unstable without problem and
without being punished.

But when build-testing packages with GUI 0.30.0 I came upon this build
failure of GDL2:

gcc EOAdaptor.m -c \
      -MMD -MP -Wdate-time -D_FORTIFY_SOURCE=2 -DGNUSTEP_BASE_LIBRARY=1 
-DGNU_RUNTIME=1 -g -DGNUSTEP -DGNUSTEP_BASE_LIBRARY=1 -DGNU_GUI_LIBRARY=1 
-DGNU_RUNTIME=1 -DGNUSTEP_BASE_LIBRARY=1 -fno-strict-aliasing -fexceptions 
-fobjc-exceptions -D_NATIVE_OBJC_EXCEPTIONS -pthread -fPIC -Wall -DGSWARN 
-DGSDIAGNOSE -Wno-import -g -O2 -g -O2 
-ffile-prefix-map=/build/gnustep-dl2-0.12.0=. -fstack-protector-strong -Wformat 
-Werror=format-security -DDEBUG -fconstant-string-class=NSConstantString 
-I../EOControl/. -I.. -I. -I/usr/local/include/GNUstep -I/usr/include/GNUstep \
       -o obj/EOAccess.obj/EOAdaptor.m.o
EOAdaptor.m:132:39: error: 'NSGB2312StringEncoding' undeclared here (not in a 
function); did you mean 'NSHZ_GB_2312StringEncoding'?
  132 |   { @"NSGB2312StringEncoding",        NSGB2312StringEncoding },
      |                                       ^~~~~~~~~~~~~~~~~~~~~~
      |                                       NSHZ_GB_2312StringEncoding
EOAdaptor.m:135:39: error: 'NSBIG5StringEncoding' undeclared here (not in a 
function); did you mean 'NSBig5StringEncoding'?
  135 |   { @"NSBIG5StringEncoding",          NSBIG5StringEncoding },
      |                                       ^~~~~~~~~~~~~~~~~~~~
      |                                       NSBig5StringEncoding
make[6]: *** [/usr/share/GNUstep/Makefiles/rules.make:521: 
obj/EOAccess.obj/EOAdaptor.m.o] Error 1

These encodings were renamed which (IMVHO) should not happen in a
point release that should be fully compatible.  There's a similar
error when building SOPE (not maintained by us, Debian GNUstep team).

The question is, what to do now?

Usually, the correct course of action is to revert the upload to
Debian and wait for upstream to make another release with a bumped
SONAME.  But in this case we'll certainly miss the deadline and we'll
end up with Base/1.28.0 and GUI/0.29.0 in the new Debian release.

Another solution, which I prefer right now as we are seriously pressed
by time, is to upload a fixed gnustep-dl2 package, send a patch to the
sope maintainer and hope that the release team won't insist for the
revert themselves.