[Debian GNUstep maintainers] GNUstep transition, orphaned packages, todo

[Yavor Doganov]

As you know already, we're going to have the transition that we missed
for wheezy two years ago.

The good news:

- Only 2 packages FTBFS (cenon.app and sogo); the latter has been
  fixed.

The bad news:

- Nobody has sponsored the new GNUstep core packages yet.
- There are a lot of packages that are going to be broken, even though
  they build successfuly.  Some of them are broken now.  I filed some
  ~30 bugs based on the warnings from the build logs, which is not a
  completely reliable way of judging whether a particular package is
  going to have trouble or not.  I'm working on these bugs now,
  starting with "my" packages, then orphaned ones, then the rest.

In git, I already split the PreferencePanes library from
systempreferences.app to separate packages, as GWorkspace needs it.
We should do the same with cynthiune.app (so that we can package
CDPlayer), gorm.app (so that GDL2 can depend on libgorm-dev) and
gworkspace.app (Addresses uses the Inspector framework).

Orphaned packages (again)
-------------------------
These packages are orphaned:
aclock.app
gridlock.app
talksoup.app
volumecontrol.app
zipper.app

I guess we'll take them under the pkg-gnustep umbrella.  VolumeControl
has an RC bug, it has to be ported to ALSA.  Zipper and AClock have
been adopted by the GAP folks and have new releases.  TalkSoup is
probably broken and would need some work.

New packages that would be nice to have packaged:

CoreBase/Opal -- needed by the new opal backend
DBusKit -- SimpleAgenda uses it; already packaged, no sponsor
SQLClient -- MPDcon uses it, Adun's SQL extension too
FisicaLab -- already packaged, no sponsor
Gemas -- text editor that integrates with PC; depends on HighlighterKit
CDPlayer -- includes the CDDB bundle as well

We have to discuss and decide what to do with the GNUstep runtime.  It
is a complex situation.  I don't think we can have it as an
alternative.  We have to switch permanently (with some major tradeoffs
like no GNUstep on many architectures) or stay with the GCC runtime.
Perhaps it would be better to have this discussion on the upstream
lists; discuss-gnustep seems to fit best.