On Wed, Apr 25, 2007 at 11:41:10PM +0200, Domenico Andreoli wrote: > > > so it would be:
> > > libcurl4-dev provide: libcurl-dev > > > libcurl4-openssl-dev provide: libcurl-dev, libcurl-ssl-dev, > > > libcurl3-openssl-dev > > > libcurl4-gnutls-dev provide: libcurl-dev, libcurl-ssl-dev, > > > libcurl3-gnutls-dev > > > libcurl-dev and libcurl-ssl-dev are already in place since the > > > non-ssl/ssl scission, long time ago. > > > my intention is to add also a non-ssl libcurl flavour with > > > libcurl4-dev. libcurl3-dev has been a transition package to install > > > libcurl3-openssl-dev. hence those depending on libcurl3-dev instead of > > > libcurl3-openssl would have a bug. > > That's incredibly lame, given that libcurl3-dev is what most packages > > build-depend on (62 out of 73, according to 'dak rm'). My entire point was > > that you shouldn't break your library's reverse-dependencies without reason! > libcurl4-openssl-dev should provide also libcurl3-dev, ok? That sounds good, thanks. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
