gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Question about GNUstep DL2


From: Yavor Doganov
Subject: Re: Question about GNUstep DL2
Date: Fri, 08 Jan 2010 15:07:07 +0200
User-agent: Wanderlust/2.15.5 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (Gojō) APEL/10.7 Emacs/23.1 (i486-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO)

David Ayers wrote:
> gnustep-dl2-nox(-dev)
>   EOControl/EOAccess

That's OK, but the runtime library package name should embed the
soname, e.g. gnustep-dl2-nox-0.  Furthermore, we'll get 2 lintian
warnings `package-name-doesnt-match-soname' while if it is libeoaccess
there would be only one (for EOControl).

> gnustep-dl2-gui(-dev) (depends on dl2-nox)
>   EOInterface

This is unjustified -- one library, so the packages should be named
libeointerface0/libeointerface-dev according to the naming convention.

> Yet if we lump them into single adpator packages, all usefull
> adaptors will pull in -gui

Right :-(

> - the adaptors (i.e. PostgreSQLAdaptor) should refrain from installing
> headers

OK, that's good to know.

> - the Renaissance dependency should be removed,

Only you can remove it in subsequent releases :-)  But it's not a
problem at all from Debian's POV.


I see too variants.

Variant 1:  Avoid dependency on -gui

libeoaccess0
  EOControl/EOAccess runtime libraries
Depends: gnustep-dl2-postresql-adaptor | gnustep-dl2-sqlite-adaptor

libeoaccess-dev
  EOControl/EOAccess headers + .so symlinks
  gdl2.make

libeointerface0
  EOInterface runtime library

libeointerface-dev
  EOInterface headers + .so symlink
Depends: libeoaccess-dev
Recommends: gnustep-dl2-postresql-adaptor-gui | gnustep-dl2-sqlite-adaptor-gui

gnustep-dl2 [1]
  DBModeler
  GDL2 palette
  eoutil, gdlgsdoc
  EOModeler (as private library)
Recommends: libeointerface-dev (which will pull in libeoaccess-dev)

gnustep-dl2-postgresql-adaptor
  The adaptor w/o LoginPanel, symlinks in /usr/lib deleted, headers
  deleted
Suggests: gnustep-dl2-postgresql-adaptor-gui

gnustep-dl2-postgresql-adaptor-gui
  The LoginPanel for this adaptor
Depends: gnustep-dl2-postgresql-adaptor

gnustep-dl2-sqlite-adaptor
  The adaptor w/o LoginPanel, symlinks in /usr/lib deleted
Suggests: gnustep-dl2-sqlite-adaptor-gui

gnustep-dl2-sqlite-adaptor-gui
  The LoginPanel for this adaptor
Depends: gnustep-dl2-sqlite-adaptor

That's 9 packages.

[1] I suggest to retain the existing `gnustep-dl2', because otherwise
    we'd need a transitional empty gnustep-dl2 package to pull in
    -devtools/-tools/whatever for existing installations, which is yet
    another binary package (although only for 1 Debian release cycle).


Variant 2:  Ignore dependency on -gui

gnustep-dl2-0
  EOControl/EOAccess/EOInterface runtime libraries
Depends: gnustep-dl2-postresql-adaptor | gnustep-dl2-sqlite-adaptor

gnustep-dl2-dev
  EOControl/EOAccess/EOInterface headers + .so symlinks
  gdl2.make

gnustep-dl2:
  DBModeler
  GDL2 palette
  eoutil, gdlgsdoc
  EOModeler (as private library)
Recommends: gnustep-dl2-dev

gnustep-dl2-postgresql-adaptor
  The adaptor with LoginPanel, symlinks in /usr/lib deleted, headers
  deleted 

gnustep-dl2-sqlite-adaptor
  The adaptor with LoginPanel, symlinks in /usr/lib deleted

That's 5 packages.

WDYT?  I'd say Federico should go with Variant 1 as it is more
flexible/convenient for end users, and more future-proof.  If sponsors
protest aloud or ftpmasters eventually reject it, revert to variant 2.
OTOH, the current gnustep-dl2 package has been dependending on -gui
for ages, so probably it is not a big problem to continue to do so.

* * *
Just a few ideas about potentially useful apps that would use GDL2.
It would be nice to have a GNUstep equivalent for Glom [2].  Anjuta
(GNOME's IDE, [3]) uses Libgda [4] for its "symbol-db" plugin (if I'm
not wrong) -- perhaps something like this would be useful for Project
Center too.

[2] http://glom.org
[3] http://gnome.org/projects/anjuta
[4] http://gnome-db.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]