On Tue, 2008-01-01 at 16:10 +1100, Hamish Moffatt wrote: > It's not a function of Debian overall but of the dependency rules in the > individual packages.
I think they will work in this case.. as we didn't break backwards compatibility in this new version of libgeda. > It's our convention to include the library major version number in the > package name (eg libgeda31). When that changes the other packages change > their dependencies from libgeda31 to libgeda32 for example. There's no > new version of libgeda31 (it's only ever from version 1.2.0) so there's > no risk of mixing eg gschem with an incompatible libgeda. > > 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. git diff 1.2.0-20070902..1.2.1-20071231 --stat libgeda libgeda/ChangeLog | 77 +++++++++++++++++++++++++++++++++++++++++ libgeda/autogen.sh | 12 ++++--- libgeda/configure.ac | 9 +++-- libgeda/include/prototype.h | 1 + libgeda/src/o_arc_basic.c | 13 +------ libgeda/src/o_attrib.c | 35 +++++++++++++++++-- libgeda/src/o_box_basic.c | 13 +------ libgeda/src/o_bus_basic.c | 14 +------- libgeda/src/o_circle_basic.c | 15 +------- libgeda/src/o_complex_basic.c | 28 +-------------- libgeda/src/o_line_basic.c | 14 +------ libgeda/src/o_list.c | 24 +++++++++---- libgeda/src/o_net_basic.c | 14 +------- libgeda/src/o_picture.c | 16 ++------- libgeda/src/o_pin_basic.c | 13 +------ libgeda/src/s_clib.c | 1 + libgeda/src/s_encoding.c | 14 +++++--- libgeda/src/s_textbuffer.c | 1 + And specifically: diff --git a/libgeda/include/prototype.h b/libgeda/include/prototype.h index 8ecd553..ec9aa4f 100644 --- a/libgeda/include/prototype.h +++ b/libgeda/include/prototype.h @@ -205,6 +205,7 @@ int o_attrib_count_toplevel(TOPLEVEL *w_current, char *name) char *o_attrib_search_toplevel_all(PAGE *page_head, char *name); OBJECT **o_attrib_return_attribs(OBJECT *object_list, OBJECT *sel_object); void o_attrib_free_returned(OBJECT **found_objects); +void o_attrib_list_copied_to(ATTRIB *list, OBJECT *to_obj); /* o_basic.c */ int inside_region(int xmin, int ymin, int xmax, int ymax, int x, int y); There have been no structure changes, and the old API should behave in the same way. (Aside from bug fixes). > I think the best way for me to fix this is to change the library package > name to libgeda31.1. 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) Best wishes, -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) _______________________________________________ geda-dev mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
