Re: Question about GNUstep DL2

[Matt Rice]

On Mon, Jan 4, 2010 at 1:37 AM, Federico Gimenez Nieto <address@hidden> wrote:
> El 03/01/2010 21:26, Matt Rice escribió:
> [.....]
>> 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).
>>
>
> AFAIK, since gorm.app is already part of debian, that package should be
> used instead of including convenience copies of code, see [1] for
> details. On fact, the current gnustep-dl2 package depends on gorm.app
> for its build and installation. But right now the public libraries of
> gorm aren't packaged as separated shared libraries, Yavor also suggested
> this as a prerrequisite, [2]
>

Ahh, sorry I meant the 'package GDL2Palette bundle with DBModeler',
adding a dependency on the existing Gorm.app package to it,
it is more of a private shared library/plugin sort of thing, not
intended to be linked to anything,
so if i understand correctly it would be alright to ship that with DBModeler?


> [.....]
>> 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
>>
>>
>
> AFAIK that could be done with a virtual package, [3]. It seems to me
> that the same functionality could be achieved with the separate
> gnustep-dl2-postgres-adaptor and gnustep-dl2-sqlite3-adaptor packages,
> including an OR'ed dependency on the related packages. What would be the
> advantages of having the EOAdaptor umbrella?
>

I think that the advantages are just mostly future-proofing, there
exist are not copyright owned by the FSF, and so they are not
distributed with GDL2, which have been ported by various people,
typically from EOF adaptors...

also with databases like oracle maintaining their own apt repository
there is potential for adaptors with non-free dependencies and so on.
I think either the virtual package or the OR'd dependencies will work
for now though.

since the 3rd party ported adaptor(s) generally lack any formal
'project' and formal release process, they're probably not eligible
for inclusion into debian, and no adaptors exist with dependencies on
non-free actually exist (to my knowledge), I think it is up to you
whether you would want to future proof for that sort of thing, or
cross that bridge if/when it is ever needed to be crossed