Re: Question about GNUstep DL2

[Matt Rice]

On Thu, Jan 7, 2010 at 1:12 PM, Yavor Doganov <address@hidden> 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,