Kevin Krammer writes: >> Anyway, both the above represent a reason to use dlopen'ing of >> normal libs, but in either case, it's a very ugly workaround, and >> should be avoided as much as possible. I wouldn't personally have >> used it in either case.
> I think there was no viable option in the case of OpenSSL, as not > having support for HTTPS is a dead end. How about checking for it at configure time, and then just linking to it ? The various version differences can be worked out at configure time as well. > Debian has a clear advantage with such problems, the highly > appreciated effort to create a fine package granularity enables > packagers to build alternative packages (one for feature disabled > and one for enabled), I suppose you're talking about the various "-ssl" packages ? As you may have noticed, these are disappearing or have already disappeared from Debian. In general, these were always workarounds, and Debian never really liked to have them. AFAIK, the reason they were necessary is so that not too much stuff should go into non-free. Anyway, IMHO, there's no point in not having ssl support in kdelibs, these days, just as there's no point in not having IDN support these days, and upstream should just make both libs a hard dependency. > but unfortunately a lot of other distributors still use huge > packages, making it necessary to detect the availablity of certain > features at runtime :( Sorry, but I don't see why the use of big packages would make this necessary. cheers domi
