hi, On Mon, Jul 18, 2005 at 03:40:30PM +0200, Olaf van der Spek wrote: > On 7/18/05, sean finney <[EMAIL PROTECTED]> wrote: > > yes, and the same with libmysqlclient, which is why there's no longer ssl > > support in the mysql packages :( > > Wouldn't it be possible to support SSL transparently in such a way > that the original package doesn't need to be modified?
not without some major dlopen-style hackery, which i don't imagine
upstream would support and neither christian nor i have the
time/interest/desire to see done in debian-specific patches.
On Mon, Jul 18, 2005 at 04:36:52PM +0200, Torsten Landschoff wrote:
> On Mon, Jul 18, 2005 at 09:29:46AM -0400, sean finney wrote:
> > yes, and the same with libmysqlclient, which is why there's no longer ssl
> > support in the mysql packages :(
>
> That kind of ... sucks!? No hope have the support GnuTLS or something?
it's totally feasible that it (and any other ssl-needing library) could
be patched to use gnutls instead of openssl, but i'm not familiar enough
with either API and would really prefer upstream to approve/include
the functionality. if somebody did the hard work and provided a patch,
and the mysql folks sounded somewhat postitive about it, i'd consider
the possibility.
of course this would all be moot if upstream authors got a clue
about the full ramifications of the GPL with their software...
On Mon, Jul 18, 2005 at 07:57:11PM +0200, Bernhard R. Link wrote:
> Well, linking against openssl where gnutls support seems to be
> available is at least an annoyance. The alternative is
> to upload an alternative libcurl, duplicating the source code,
> making it harder for everyone involved. So it is more than just
> a avarage wishlist-bug where the maintainer's opinion is the last
> word.
the problem, from what i understand and from what istr, is that the
API's aren't bit-for-bit compatible. given that openssl is not likely
to change their license scheme any time soon, moving to something like
gnutls does seem the preferable way to go supposing that someone is
willing to do and maintain the work.
however, it still very much is ultimately the maintainer's perogative
whether or not to accept such an option, at least in the situation
where upstream only supports openssl. if upstream supports both,
you probably won't have a hard time convincing them to change over,
and if not you'd at least have a leg to stand on with the technical
comittee.
sean
--
signature.asc
Description: Digital signature
