Re: Question about GNUstep DL2

[Yavor Doganov]

Matt Rice wrote:
> Yavor mentions that "(although they're intended to be public
> libraries, nothing in GNUstep uses them)"

Oh, that was misleading.  What I meant is that no package in Debian
currently uses gnustep-dl2 (its libraries or whatever).

> but DBModeler isn't really a standalone application, the model files
> it generates are intended to be used by the libraries,

...which in turn are used by applications, right?  That's what I was
saying.  But we'll ship all libraries anyway, the question was how.

> the EOControl/EOAccess split from EOInterface would just be nice in
> the case where someone wants to install something like a GSWeb
> application onto a web server, where EOInterface in X and
> gnustep-gui and a lot of unnecessary stuff

I agree it would be nice.

> I'm not sure if it would be against debian policy to ship the Gorm
> bundle with DBModeler.app

Yes, that's perfectly fine.

> gnustep-dl2-libs/gnustep-dl2-libs-dev:
> EOControl -> gnustep-base
> EOAccess -> EOControl

This won't work, the package will have the same problem as the
gnustep-dl2 package now.  Let me explain simply the policy.  Every
shared library (in /lib and /usr/lib) should be packaged as libfooN
and libfoo-dev (in rare cases libfoo2-dev).  This is to allow packages
that use the library to depend on libfoo-dev and to automatically
generate the libfooN dependency of the binary package via the "shlibs"
mechanism.  Embeding the soname "N" in the package name is essential
to handle library transitions.  Packages without reverse dependencies
(e.g. all of gnustep-dl2's libraries) are considered harmful, as the
main reason for packaging a library is to handle properly dependencies
for stuff (in the distro) that uses it.  They're basically clutter --
it is considered that if a library is interesting, useful and mature,
people will develop apps that make use of it.  More binary packages
also adds extra load on the Debian infrastructure.

(For example: libCynthiune is intended by its author to be a public
library, allowing people to develop third-party bundles for Cynthiune.
But since no such bundles exist, we ship it under
/usr/lib/cynthiune.app within a single cynthiune.app package.  If
someone writes a bundle or two worth packaging some day, we'll split
the library in libcynthiune0/libcynthiune-dev.  Now it would be a
waste.)

Anyway, I explicitly assume that we're going to ship all EO* libraries
as public libraries, to help users who might eventually develop useful
free software (or easily build manually what is available but not yet
packaged).  GDL2 is more than a music player, after all :-)

So, having said that the binary package name must match the soname,
the above pair should be libeoaccess0/libeoaccess-dev, but that would
be again a violation because it includes EOControl as well.  This is
allowed in certain situations (for example, libglib2.0-0 contains 5
tightly related libraries) when the libraries are meant to evolve
together.  Is that the case here?

> gnustep-dl2-interface/gnustep-dl2-interface-dev:
> EOInterface -> EOAccess + gnustep-gui

Likewise, this should be libeointerface0/libeointerface-dev.  But you
didn't mention EOModeler.  Is its place here, too?  If so, what I said
above applies here as well.

> gnustep-dl2-devtools:
> GDL2Palette -> EOInterface + Gorm libs
> DBModeler -> EOInterface + renaissance

Or gnustep-dl2-tools, gnustep-dl2-bin, or simply gnustep-dl2.  Perhaps
-devtools is most descriptive.  I guess this is the place to include
eoutil, gdlgsdoc and gdl2.make, right?

> gnustep-dl2-postgres-adaptor:
> Postgres adaptor -> EOAccess + Postgres libs (build dep on gui for the
> login panel [1])

I sense some confusion here.  There is going to be one gnustep-dl2
source package, which already build-depends on libgnustep-gui-dev.
(Build-Depends/Depends for source/binary packages in Debian are what
Build-Requires/Requires are in the rpm world for SRPM/RPM.)

Here we'll hit the same problem, as there are libPostgreSQLEOAdaptor
and libSQLite3EOAdaptor in /usr/lib.  Is something intendend to link
against these libraries?  Correct me if I'm wrong, but by quick
uneducated glance at EOAccess they are dynamically discovered and
loaded by NSBundle methods.  I wonder why they're developed as
frameworks then...  Is it safe to remove the symlinks for them in
/usr/lib?  NSBundle will look at the GNUstep paths, so it seems this
is an acceptable solution.  I suspect I'm missing something important,
though.

Assuming it's possible to rm the stuff at /usr/lib, these packages'
names look fine to me.  Perhaps the split is not entirely necessary,
given that the database library dependencies are tiny.  But well, in
an ideal world, it's nice to have them split.

One more question...  Isn't at least one adaptor necessary to be
present on the system?  Or is it optional -- i.e. neither can be
installed, either, or both?

Federico Gimenez Nieto wrote:
> AFAIK, since gorm.app is already part of debian, that package should
> be used instead of including convenience copies of code,

But there's no convenience code AFAICT.  The GDL2 palette includes
public Gorm headers, and links against libGorm, which is what one
would normally do when developing a palette.  It's just that gorm.app
in Debian has the same packaging problem as the current gnustep-dl2
package.  Entirely our fault.  When it is fixed, you'll simply
build-depend on libgorm-dev, and the gnustep-dl2-devtools dependency
on libgorm0 will come via ${shlibs:Depends}.  You would then simply
let it Recommend: gorm.app to indicate that one component of the
package is only useful with gorm.app, but it's not strictly
necessary.

> AFAIK that could be done with a virtual package, [3].

It smells like overprojecting to me.  I would let libeoaccess0
Recommends: gnustep-dl2-postgres-adaptor | gnustep-dl2-sqlite3-adaptor

(Or Depends: if at least one adaptor is required.)


* * *
On a more general note -- are there useful, stable, free software
applications using GDL2 that are worth packaging now?  The only one I
know of is GNUstepWeb, but I'm not sure about its maturity status.
Packaging stuff that uses GDL2's libs is the best possible way to deal
with the problem at hand, both from the distro management and user
perspective :-)