On Thu, Jan 7, 2010 at 1:12 PM, Yavor Doganov <ya...@gnu.org> wrote: > Matt Rice wrote: >> > Likewise, this should be libeointerface0/libeointerface-dev. But >> > you didn't mention EOModeler. Is its place here, too? >> >> Ahh, yeah I forgot about that library, no EOModeler can go in its own >> libeomodeler > > But the goal is to decrease the number of the binary packages as much > as possible... > If EOControl/EOAccess are together, this makes > > 6 library packages + 2 adaptors + -devtools = 9 packages :-(
forgive me I am confused I was under the assumption that debian policy forced us to split EOAccess/EOControl. > If EOModeler is acceptable (from upstream's POV) to be shipped > together with EOInterface, the number is 7 which is more palatable. sure, but it makes more sense to ship with DBModeler/devtools IMO, the EOModeler library is to DBModeler what libcynthiune in your previous example is to cynthiune. used to write bundles for extending DBModeler, similarly there no real bundles actively in use that use it, but it should straight forward to port bundles from the original EOModeler, of which there are a few available, but I haven't bothered to port them. It could be shipped with EOInterface, but the connection between the 2 is more tenuous in that the only thing they have in common is that they use gui, and DBModeler has dependencies on both, while EOInterface is useful without DBModeler installed (in the context of an application depending on EOInterface) the EOModeler library is not. DBModeler is in fact a bunch of EOModeler bundles which instead of being dynamically loaded, are linked directly into the application + a main loop. I'm much less averse to debian installing EOInterface private with devtools than EOAccess/EOControl, if you feel the need to bundle that with devtools privately go ahead, the package while not complete would still be useful to the largest portion of the target audience, then EOModeler/EOInterface could be split out if they are needed by bundles/applications. >What about OGO/SOGo? IIRC they maintained their own fork of >gnustep-dl2, or maybe it was not a fork but a different >implementation? (Not that we have the manpower to maintain a big >thing like SOGo, but still...) OGO uses a fork of parts of gdl1, so I'd assume that SOGO does too, _______________________________________________ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev