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/ _______________________________________________ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev