On Wed, Mar 07, 2007 at 04:15:33PM +0000, Reuben Thomas wrote: > On Wed, 7 Mar 2007, Domenico Andreoli wrote: > > >this is a problem i cannot solve. unfortunately these two packages > >have to conflict each other, they provide overlapping files. only one > >of them may be installed at the same time. sorry. > > This is clearly a problem that can be solved in principle: simply have two > versions of libcurl. Other packages would normally provide overlapping > files, e.g. different versions of the libdb libraries or the Lua > interpreter, but they are packaged with version numbers appended and the > problem is solved. With curl it's backend-library names rather than version > numbers, but why won't the same sort of solution work?
indeed you may install both openssl and gnutls version of the library binary (starting from 7.16.1 i restored also the plain no-ssl version!). but here we are talking of the development files. tipical curl program #include <curl/easy.h>. appending version makes all this software break, requiring it to include something like <curl-gnutls/easy.h>. i already hear people saying, ah.. in the debian wonderland you have to make weird things to build with curl (no please). of course we could use alternatives and let the admin point /usr/include/curl to whatever she likes but i'm sure things would start to break badly here (ie. libraries depending on libcurl4-gnutls-dev taking for granted that /usr/include/curl points to /use/include/curl-gnutls while the admin today chose to make it point to /usr/include/curl-openssl). what a mess, to solve what? situation is now under control using package relationships, maybe a little strong but it's safe. cheers domenico -----[ Domenico Andreoli, aka cavok --[ http://people.debian.org/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
