[Debian GNUstep maintainers] GNUstep transition, Gorm/1.4.0 and forthcoming changes to gnustep-dl2 + steptalk

[Yavor Doganov]

Sorry for replying to myself..

On Thu, 13 Jun 2024 19:28:38 +0300,
Yavor Doganov wrote:
> As you may have seen, we're about to have another GNUstep transition.
> Everything's ready, we're just waiting for release team's approval.

Transition already approved, uploads of the GNUstep core packages to
unstable will happen at tarzeau's discretion and subsequent binNMUs
will happen at RT's discretion.

>   * Perhaps split EOInterface as a separate package.  People have
>     complained in the past that lumping together EOControl, EOAccess
>     and EOInterface into one package pulls in GUI which is undesirable
>     (GDL2 is mostly used on servers).  The only problem I see here is
>     that it will be yet another library in Debian without rdeps, so
>     I'm leaning to not doing this.  Another option is to dump it
>     entirely (with the appropriate NEWS entry).  Comments welcome.

The GDL2 palette links with EOInterface so we cannot remove it.  We
can move it to the gnustep-dl2 package as a private library but I'm
reluctant to do this.  We don't actually know how many users rely on
it (for private/custom software), it is advertised everywhere in GDL2
documentation so removal (or making it unusable for developers as a
private library) would be somewhat drastic.

We can move it to a new set of library packages
(libeointerface0deb/libeointerface-dev) in order to eliminate the
dependency on GUI but on second thought I think it's not worth it.
EOAccess needs at least one adaptor available and they have login
panels which depend on GUI.  The adaptors are only recommended but
that's only because we had to fix a circular dependency (the adaptor
packages themselves depend on the library package).  So unless we
split the login panels into separate packages (IMO overkill) this
operation is useless.

>   * Perhaps ship gdl2gsdoc (I don't remember what the problem was last
>     time I looked at it).

It was due to a bug fixed upstream 14 years ago.  Included now.

> For steptalk I intend to do more or less of the same

I'm currently working on it, nearing to the final.  There's an ABI
break here as well.  In fact, we introduced an ABI break with a patch
10 years ago but it remained unnoticed...

I've split the modules into new packages: steptalk-gui-module
(recommended by the library according to the upstream build setup
which makes it optional but enabled by default), steptalk-gdl2-module
(suggested) and a new one steptalk-sqlclient-module (also suggested).