hi, On Mon, Jul 18, 2005 at 03:40:30PM +0200, Olaf van der Spek wrote: > On 7/18/05, sean finney <seanius@debian.org> 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 --
Attachment:
signature.asc
Description: Digital signature