On Fri, Mar 17, 2006 at 07:52:45AM +0100, Martin Costabel wrote: > ?? ?? wrote: > [] > >Meanwhile, $(head -2 unstable/main/finkinfo/gnome/gtk+2.info) says: > >>Package: gtk+2 > >> > >># do not upgrade to 2.8.x until cairo InheritedBuildDepends issue is > >>resolved! > > Is there any explanation of that "cairo InheritedBuildDepends issue" > anywhere?
In part, it's the same situation we have whenever we alter an existing package to link against a new library: gtk+2 2.8 links against cairo, whereas older versions do not (we specifically disable it in our gtk+2 2.6.x packages) so new gtk's .pc and .la will have -lcairo (or something equivalent) added. That causes anything that links against this new gtk to also link against cairo. Anything that links against gtk will have to be given a BuildDepends:cairo in order to be able to be built when new gtk is present. That can almost certainly be scripted. This massively changes lots of .deb, but often IMO not substantially more than any other case where compatibility_version of a dependent library increases. In theory, we must rev-up, but I don't know in practice here. The new .deb will have a missing Depends:cairo-shlibs, but assuming new gtk is installed (which obviously *would* declare Depends:cairo-shlibs), that's okay. If user downgrades the gtk package, the recursive dependency would be lost, but the old(er than used for linking) gtk wouldn't suffice for compatibility_version reasons anyway. There are a few packages that really do need rev-up, since they enable whole new libraries and various features if gtk has cairo (or if they use a package that adds new features in this manner). We could manually edit gtk's .pc and .la to remove the cairo links, so packages that rely on those files for linking information would not link directly to cairo. OTOH, I don't know if the gtk linker flags modulo the cairo ones are sufficient to link against a cairo-enabled gtk (thanks to Apple's linker not allowing indirect symbol references). Another big concern is a rumor that "adding cairo support" is not transparent to things that use gtk (i.e., it's not just a back-end plugin). If liba links against libb and libb links against libc and these all link against gtk+2, consider what happens if just libb is recompiled after cairo is enabled in gtk. Will this libb be passing data back to liba or down to libc that liba and libc aren't able to handle? We'd essentially have a mini version of the gcc3.3->gcc4 dist-upgrade situation. For one reference touching on those last two issues, see: http://lists.freedesktop.org/archives/pkg-config/2005-October/000036.html dan -- Daniel Macks [EMAIL PROTECTED] http://www.netspace.org/~dmacks ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
