On Monday 12 April 2004 13:13, Dominique Devriese wrote: > 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. I guess this would be possible, no idea why it wasn't done this way. > > 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. I think it was a problem with export laws and encryption. > 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. True. > > 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. Because you would have to create alternativ versions of the same package when any single program of it has more than one option, e.g. four times kdebase if two programs have non-related optional builds. Cheers, Kevin
Attachment:
pgpvPUR90YLGX.pgp
Description: signature