[Debian GNUstep maintainers] gnustep-dl2 ready for review

[Yavor Doganov]

Federico Gimenez Nieto wrote:
> I added a build dependency on librenaissance0-dev that solved the
> issue, don't know if this is the best option.

That's the right thing to do as this release started to depend on
Renaissance.

> -I've just made the package with the same structure that it had, i
> didn't attemp to follow Yavor's advice [2] about splitting the package
> in DBModeller.app and gnustep-dl2 with the tools and the libEO*
> libraries shipped in /usr/lib/gnustep-dl2, and not in /usr/lib (there
> are some lintian warnings that may be related to this).

Well, it would be OK if DBModeller.app + the tools are in the
gnustep-dl2 package, there is no reason to split them actually.  For
the libraries, lintian is right to complain.

> I don't know exactly how to begin with this, any suggestion?

There are 3 options AFAICS.

1) Move all of them in /usr/lib/gnustep-dl2 as private libraries.
   (See adun.app [1] for an easy way to do this.) However, I don't
   know how many things will break for other people.
   OpenGroupware.org and/or SOGo used to depend on this package, but
   IIRC they maintained their own fork.  Maybe that's not true today.
   Also, there are other things as GNUstepWeb that use GDL2.

2) Package the libraries en-bloc into libgnustep-dl2-0 (runtime) and
   libgnustep-dl2-dev (headers, etc.).  This means that you'll have to
   bump the soname even if a single library from the stack changes its
   ABI.  This is not a problem at all, because there are no reverse
   dependencies and transitions involved.  I'd probably go for this.

3) Package them in the classic way -- each shared library in separate
   runtime and development packages.  This will result in a truckload
   of extra packages; I don't think it's justified given that no
   official Debian package uses them today.

So, what I suggest is to ask on gnustep-dev at gnu.org (or David Ayers
directly -- a very nice guy) what they consider as the best solution.
As I'm not aware where/how GDL2 is used, I'm not sure if option 1)
would lead to lots of angry people.  Anyway, the package as it is now
is not Policy-compliant, so something should be done about this.
Maybe it is a good idea to ask on -mentors as well, it's quite
possible that I'm missing something.

> -lintian also reports that DBModeler, eoutil and gdlgsdoc are
> binaries without manpage, should i prepare a manpage for them?

Yes, unfortunately that's a Policy requirement.

> As always, your reviews/comments are more than welcome.

Looks good in general except the libraries problem.

* There are some dpkg-shlibdeps (legitimate) warnings, can you fix
  them?  Let me know if you need any help.

* Since you move things to /usr/share, invoke gsdh_gnustep and add
  ${gnustep:Depends} to Depends as a safety measure.

* mv $(d_app)$(GNUSTEP_SYSTEM_APPS)/../ApplicationSupport/ ...
  That's $(GNUSTEP_SYSTEM_APPLICATION_SUPPORT).

* You can safely drop gnustep-make from Build-Depends, it is
  guaranteed to be pulled in by the dependency chain.

Thanks for your work.

[1]
$ ls /usr/lib/adun.app
libadun_base.so        libAdunKernel.so.0.13  libULFramework.so.0
libadun_base.so.0      libMolTalk.so          libULFramework.so.0.6
libadun_base.so.0.0.1  libMolTalk.so.3        libXMLLib.so
libAdunKernel.so       libMolTalk.so.3.0.1    libXMLLib.so.0
libAdunKernel.so.0     libULFramework.so      libXMLLib.so.0.1