Re: Question about GNUstep DL2

[Matt Rice]

On Mon, Jan 4, 2010 at 5:31 AM, Yavor Doganov <address@hidden> wrote:
> 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?

I see, splitting these up should be fine, IMO, (now that gdl2.make no
longer automatically links to both EOAccess/EOControl)
the main reason i lumped them together is that it is very rarely that
anything will depend on EOControl without EOAccess, and EOAccess
shouldn't bring in any additional dependencies.


>> 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.

Ahh, yeah I forgot about that library, no EOModeler can go in its own
libeomodeler

>> 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?

OK with me, I'm not exactly sure what to do with gdl2.make, but I'm
kinda guessing that it should go with the headers for
EOControl/EOAccess, but not knowing how/if applications are using it
since the changes described above, so i can't exactly give you a good
answer on that.  Though it does provide command line preprocessor
definitions which presumably some application could be using when
compiling software ported to gdl2, from EOF.

>> 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.

You are correct.

> I wonder why they're developed as
> frameworks then...

They are developed as frameworks, because under OPENSTEP there was no
Bundles/ directory, or place where bundles were installed outside of
an applications resources, adaptors are not application specific, and
technically a framework is a type of bundle.  A framework can either
be loaded dynamically or linked to at compilation time. GDL2 only
links to them dynamically...

the SQLite3 adaptor doesnt install any headers, but the PostgreSQL
adaptor appears to, whether there is any interface in there people can
use on top of the standard adaptor ones I don't really know.

> Is it safe to remove the symlinks for them in
> /usr/lib?

*shrug*, probably

> 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?

either or both, is the recommendation, you could potentially get some
use out of neither if you were using a 3rd party adaptor, but for a
usable installation i would recommend 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 :-)
>

Not really, most of the software using gdl2 is non-free, there is
GSWeb as you say, and some GSWeb software, e.g. intars.sf.net
(which doesn't actually use gdl2, merely depends on it, though the
gdl2 portions of GSWeb appear to go unused) but i don't see a source
download, outside of svn, oddly enough just what appears to be a
customized debian distribution with the depdencies, and stuff, also
there is http://code.google.com/p/eeframework/, I don't really know
anything about either of these projects, and neither of them use gdl2,
merely depend on it because GSWeb does.

I have some stuff like a GSWeb based music player, which uses gdl2 for
the ratings and what not, and an IRC bot which uses gdl2, but nothing
which I would qualify as stable, useful, and worth packaging now.

but honestly most GDL2 usage has centered around porting of legacy
non-free applications from EOF, so the biggest benefit currently for
GDL2 packages is going to come from server operators ability to run on
a standard debian distribution, rather than a customized one.  So
whether debian packages it or not because of the lack of free software
using it is up to you guys, just IMHO packaging DBModeler.app and
making EOAccess/EOControl private is not going to be very useful.