[Debian GNUstep maintainers] Bug#885786: gnustep-back: Please drop art backend package

[Yavor Doganov]

[ Dropping Jeremy from CC; I guess this message doesn't concern him. ]

On Sat, 30 Dec 2017 02:59:18 +0200,
Yavor Doganov wrote:
> There are several options:
> 
>   1) Wait for the opal or wayland backends to be labelled "ready for
>      release".  We can drop art immediately then.
> 
>   2) Package the old xlib backend.  This is even more deprecated; the
>      only good news is that Xlib is not going away soon.
> 
>   3) Take libart under our umbrella.  (Provided it's a viable option
>      in the first place.)
> 
>   4) Just leave the cairo backend.

Here are some details:

1) The opal backend depends on the Opal library which requires GNUstep
   CoreBase.  I filed an ITP for it some time ago (#752553) but it was
   not uploaded as I found out some issues.  IIRC, the SVN trunk (back
   then) has had some ABI-incompatible changes but the SONAME was not
   bumped, so I had doubts about upstream's plans regarding longterm
   API/ABI stability.  Some symbols which were exported in 0.1.1 were
   marked as private and I was going to ask if they were
   unintentionally exported in the initial release or there's
   something else into it.  There was an ABI break between 0.1 and
   0.1.1, if I'm not mistaken.  And there hasn't been a new upstream
   release since a very long time.

   The Opal library will clash with src:opal in Debian, something I
   have reported upstream in 2014 [1].  While the source package name
   can be src:gnustep-opal, the issue with the binary package names
   and the actual library SONAME remains.  Additionally, Opal requires
   an old version of the lcms library (src:lcms was removed from
   Debian in 2014) so it can't be packaged anyway.  Finally, there
   have been no upstream releases at all.

   [1] https://savannah.gnu.org/bugs/?42606

2) The xlib backend comes with an additional tool: font_cacher.  It's
   launched automatically by the backend and generates the cache as
   archived data in ~/GNUstep/Library/Fonts/Cache.  It has the same
   problem as the gnustep-back-common's postinst: the cache must be
   updated manually when a font package is installed or removed.
   While this can be solved for art by fixing the fontconfig bug, I
   don't see a way to do it here.  Slightly archaic even for me.

   There's a manpage to be written; that's easy.  The font_cacher tool
   must be shipped in the -common package as the -xlib package will be
   versioned.

3) It looks like a completely dead project indeed.  I was surprised by
   the low bug count.  This doesn't mean it has no bugs, most probably
   it is because the library is basically unused these days.  There
   are some patches floating around which might be worth
   incorporating should we decide to go that route.

   As more distros are going to remove libart in the near future, if
   we adopt it we must do so with the state of mind that we're
   completely on our own and must fix all issues ourselves.

4) This is straightforward but not a viable option IMHO.


I think at this point we should do 2) as it does no harm.  The package
is going to pass through NEW anyway so we can do it right now for the
fortchoming transition.  The xlib backend can be dropped anytime if we
find out that it's too buggy for a stable release, if opal is packaged
or we decide to retain the art backend (by adopting the libart-lgpl
package).

Comments?