On Tue, Jan 01, 2008 at 09:04:55PM +0000, Peter Clifton wrote: > On Tue, 2008-01-01 at 16:10 +1100, Hamish Moffatt wrote: > > But now there is a new libgeda31 which isn't compatible. The minor > > version isn't included in the library filename, and the dynamic linker > > doesn't care about it either. > > The new libgeda31 should be backward compatible, as we didn't break ABI. > What it does do, however.. is add API. This won't break any apps > requiring the old libgeda31. What it does mean however, is that > geda-gschem-1.2.1 should depend on libgeda31 >= 1.2.1 > > Any other gEDA package still installed which required libgeda31 >= 1.2.0 > will still work fine with this library. > [..] > > This should "just work" if it is called libgeda31. I just checked > packages.debianorg. The 1.2.0 released gEDA packages depend on libgeda31 > (>= 1:1.2.0) which will be satisfied by this newer version of libgeda31. > If installing this new libgeda31 broke any of the 1.2.0 versions of the > apps, then yes, we would have a problem. In this case, I don't think we > do. geda-gschem-1.2.1 will just need to depend on libgeda31 (>= 1:1.2.1)
Your reasoning is correct. However, installing new libgeda31 (1.2.1) does break the installed 1.2.0 applications. gschem segfaults on startup for me. Now I'm a little stuck. I have started work on the libgeda31.1 rename but not finished all of it yet. I have not yet tried Peter Brett's patch. Ales says that this version is not expected to be compatible with 1.2.0 anyway (despite the major version number indicating otherwise to the dynamic linker). I would appreciate some guidance on this issue :-) Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> _______________________________________________ geda-dev mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
