2010/1/3 Federico Giménez Nieto <fgime...@coit.es>: > 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. _______________________________________________ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
