Re: Question about GNUstep DL2

[Matt Rice]

2010/1/3 Federico Giménez Nieto <address@hidden>:
> Hi all,
>
> I'm in the process to adopt gnustep-dl2 debian package, [1]. You can
> check the progress so far at [2]. In order to comply with Debian
> Policy, Yavor Doganov (Cc'ed) suggested that the libraries in the
> package (libEO*) should be packaged separately from dbmodeler.app
> ([3], [4]). As Yavor pointed out, there are at least three
> alternatives for packaging the libraries:
>
> - As private libraries.
> - Bundled into libgnustep-dl2-0 and libgnustep-dl2-dev.
> - Separately as libraries on their own.
>
> What do you think would be the best option to do so?

In my opinion the best option would be to do the libraries separately
on their own,
or possibly just split the EOControl/EOAccess into one package, and
EOInterface/GDL2Palette into another package
with a 3rd package for DBModeler, or package DBModeler/GDL2Palette together

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

but DBModeler isn't really a standalone application, the model files
it generates are intended to be used by the libraries,
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'm not sure if it would be against debian policy to ship the Gorm
bundle with DBModeler.app that is another option if possible since the
gorm bundle is like a plugin for Gorm which DBModeler communicates
with, its not entirely necessary, but is required to use DBModeler
with gorm, and only DBModeler uses it (communicating via the
pasteboard).

lastly there are the adaptors which pull in the various database
dependencies (Postgres/SQLite3 at the moment) those could be bundled
separately... anyhow here is how i'd consider with silly made up
package names followed by the basic components and their dependencies

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

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

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

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

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

(and possibly a convenience package to install the whole shebang)

then in the future things like GSWeb could just go
GSWeb -> EOAccess + apache
and some EOInterface using application wouldn't necessarily need Gorm
and DBModeler. so it could just depend on EOInterface.

so the dependency tree at least has 3 ways of growth
server based/headless applications, gui applications, and developer tools

I don't really know anything about debian packaging so i'm not sure if
you could do some meta package, where Postgres adaptor/SQLite3 adaptor
provide a 'EOAdaptor' and these are recommended by EOAccess, but not
mutually exclusive so either/both could be installed

quite a few packages, but that sort of package layout would mimic the
various configurations available to those who build the package from
source.

[1] most of the components of GDL2 don't change based on how it is
configured, they just enable and disable whole components
the only exception to this (that I can think of at the moment) is the
login panel code contained in the EOAdaptors, which enables a separate
shared library containing gui code, gui apps can call login panel
associated methods, which loads the bundle if gui is found at runtime,
these may need to be split out into their own e.g.
gnustep-dl2-postgresql-loginpanel package to avoid bringing in gui
just for the login panel which should be optional, to allow debian to
maintain the dependency on gui.  Currently there is no way to build
the login panel, while installing it separately, ripping out the
LoginPanel.bundle directory from the adaptor's .framework/Resources
into its own package would work, but it isn't exactly elegant.

anyhow, i believe you could possibly get away with a single top-level
configure/make
then make -C Component DESTDIR=/path/to/package/dir install
hopefully this helps, let us know if there is anything we can do on
the GDL2 side to make your job as packager any easier.

Thanks.