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

[Yavor Doganov]

Hi,

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.
When the transition begins (that is, when -base, -gui and -back are
uploaded to unstable), please refrain from any uploads except those
that fix bugs preventing the GNUstep stack's migration to testing.

The new Gorm release has the Gorm library renamed to InterfaceBuilder
which triggers some subsequent changes down in the dependency chain.

gorm/1.4.0-3 is in experimental and finally built everywhere except
alpha (buildds lagging behind) but it will be uploaded to unstable
*after* the GNUstep transition is complete and *after* we're ready
with the reverse dependencies.

I'm working on gnustep-dl2 right now, it has been in miserable shape
for quite some time.  I decided to start off an upstream git snapshot
because the current release is very old and there are so many bugs
that cherry-picking fixes is rather burdensome.  As I told Alex in a
private exchange, this would almost certainly mean another ABI change
(confirmed after I examined the diff).  We already had one when we had
to apply some patches that broke the ABI.

So, these are the changes I plan for gnustep-dl2:

  * Set new debian-specific ABI (0deb instead of 0d).
  * Move documentation to a new gnustep-dl2-doc package (as we're
    going to pass through NEW, now is a good time to do this).
  * 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.
  * Perhaps ship gdl2gsdoc (I don't remember what the problem was last
    time I looked at it).

I've successfully built this new gnustep-dl2 snapshot (after removing
and refreshing lots of patches) but there are two hurdles:

  * I had to add gorm.app to Build-Depends.  The GDL2 palette imports
    <GormCore/GormDocument.h> -- GormCore is supposed to be a public
    library but we don't ship it as such because there are no rdeps.
    In previous Gorm releases, GormCore was built as a library so its
    headers were available in the libgorm-dev package.  Now it's built
    as a framework (sic) so headers are in gorm.app.  It's a similar
    situation with Gemas (not packaged) which needs a ProjectCenter
    header but doesn't link with the library.
  * Even if I manage to finish the work with gnustep-dl2 before the
    GNUstep transition, the new package cannot be uploaded to
    experimental because it build-depends on Renaissance.  I'm
    currently building it with sbuild's --extra-package option(s)
    pointing to renaissance binary packages that are locally built
    against the new GNUstep core libraries.  It can be uploaded only
    after renaissance is binNMUed; IOW, post-transition.

For steptalk I intend to do more or less of the same (upstream
complained loudly that it depends on _both_ GUI and GDL2).  Maybe it's
a good idea to make the main library package depend on -base only,
recommend the -gui module and only suggest the -gdl2 one.  It's also
in very poor shape, so I'll see how it goes with a git snapshot.  If
there's no ABI break, we'll have a gnustep-dl2 transition (with only
one rdep steptalk).  If there is, we'll have a steptalk transition
(with only one rdep adun.app).  All of this starting with the upload
of gorm.app to unstable, of course.

In any case, this stuff will wait for the main GNUstep transition.

I am curious to know what the team members think about the EOInterface
case.  (BTW, who are the active team members?)