On Tue, 3 Apr 2007, Michal Marek wrote: > Richard Guenther wrote: > > On Mon, 2 Apr 2007, Michal Marek wrote: > > > >> Richard Guenther wrote: > >>> The library packaging policy forces you to split off a libcurl4 package > >>> with just the libcurl.so.4* shared libraries. > >> While you're at it, cosider splittig a curl-ca-bundle or curl-data or > >> whatever, containing the file /usr/share/curl/curl-ca-bundle.crt, > >> otherwise libcurl4 would have to depend on the main package anyway, > >> which is what you're trying to avoid. > > > > Does it not work at all without that file? > > libcurl won't be able to verify SSL certificates and will fail to > download files from https: by default. The ZYPP people wouldn't be happy > about that ;-) > > > > Do old curl libraries work with a new file? > > Yes, in fact the filename is just passed to openSSL, curl doesn't care > about the content. And yes, the compat-curl* packages have been broken > from the begining, because they don't depend on the package containing > the curl-ca-bundle.crt file (they rely on the fact that a standard > install will have curl.rpm installed). > > > > In the latter case depending on curl wouldn't be that > > bad, or at least one curl-ca-bundle rpm would be enough for all old > > versions. > > So what do you suggest, depending on the curl package, or splitting off > a curl-ca-bundle package? Note that the first solution would create a > circular dependency between curl and the latest libcurl*, which ZYPP > doesn't like.
I have splitted off a curl-ca-bundle package and depend on that from libcurl4 now. For old compat libraries like libcurl3 I'll just depend on /usr/share/curl/curl-ca-bundle.crt instead. > Michael Matz wrote: > > Richard is trying to fill a policy with life. Any other cleanups > > following from that should be done by the packager. > > Well, if Richard told me "Hey Michal, fix your package!", I would simply > do it myselves. I just wanted to point out that just splitting off the > shared libs could break functionality in this case. Second, I don't know > how to best apply the policy in such case. Yes, I think it's good to tackle some problematic cases like this to see if we can get it right. Richard. -- Richard Guenther <[EMAIL PROTECTED]> Novell / SUSE Labs SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746 - GF: Markus Rex --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
