At Thu, 25 Mar 2010 23:07:11 +0100,
Bill Allombert wrote:
> On Mon, Mar 22, 2010 at 03:06:00PM +0200, Yavor Doganov wrote:
> > libEOAccess (from libgnustep-dl2-0) needs at least one adaptor to
> > be present/installed -- it might be either one from the
> > gnustep-dl2 package (-postgresql or -sqlite), or it might be a
> > proprietary one which I anticipate will never be packaged for
> > Debian. Anything using the library will fail miserably with
> > SIGABRT if no adaptor is found -- the code dynamically discovers
> > the available adaptors by searching the standard GNUstep Bundles
> > path.
>
> Well, assuming the adaptors cannot be used outside of
> libgnustep-dl2-0,
That's certainly so.
> then they do not really need to depend on libgnustep-dl2-0, so their
> shlibs dependency can be trimmed.
Yes, this is possible right now, but...
> However if the interface of libgnustep-dl2-0 change then there must
> be a mechanism that prevent libgnustep-dl2-0 to load an adaptor for
> the wrong interface.
The interface of all EO* libraries shipped in libgnustep-dl2-0 is
likely to change at some point in the future (as is for all shared
libraries in the distro). In fact it changed several times in the
past, but because no package in Debian uses these libraries, these
changes remained unnoticed (perhaps even by upstream, as the SONAMEs
didn't change).
I think that *provided* the adaptors are built from the same source
package, it is OK to trim their dependency on libgnustep-dl2-0, as it
is guaranteed that they will migrate together to testing and a prudent
user (except those manually installing .debs) will be guaranteed to
have compatible adapror + libEOAccess. (As an additional safety, we
can let the runtime library package depend on the exact
${binary:Version} of the ORed adaptor package.) Installing an adaptor
will not pull libgnustep-dl2-0, but that is a useless activity anyway
if one does not use DBModeler.app (from gnustep-dl2) or some custom
GDL2-based thingy.
Am I right here?
If one day upstream decides to ship the adaptors in separate
package(s) (very unlikely), the situation changes drastically as the
adaptors need to (build-)depend on the proper version of the
librari{y,ies} packages. Solving the circular dependency issue would
need rethinking, then. Right now, my personal humble opinion is that
it is fixable with implementing the solution you proposed.
All comments welcome, as I don't feel confident in this tricky area.
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
