Re: GnuCash 1.7.6 release delayed

[Rob Browning]

Chris Lyttle <address@hidden> writes:

> Well as I've already delayed it, I dont mind waiting till Sunday to
> make a decision whether to release GnuCash 1.7.6 with g-wrap 1.3.4
> or not.  Lets make it like this, if you are unable to get things
> fixed to your satisfaction by say, sat evening, we can go with
> releasing with 1.3.4, otherwise we can go with whatever new version
> you have (unless you don't think that is enough time).

One of the main solutions that's been proposed for the problems with
add-on libs (not just for guile, but for perl, gtk, etc.) is to just
*require* a particular version of any sub-libraries at configure time
for a given release of a library.  i.e. in this case gwrap would
refuse to compile against anything but guile-1.6, but in the gnucash
case is that even feasible?  AFAIK RH only recently moved from 1.3.4
to 1.4.

One of the only other viable solutions proposed is for add-on libs to
dynamically pick their soname at configure time based on the versions
of the sub-libs they're compiling against, but again, this doesn't
seem like it will scale very well.  Presuming I understand the
proposed solution, if compiling against guile 1.4, we might have
libgwrap-glib.so.1, but if compiling against guile 1.6, we might have
libgwrap-glib.so.2.  Of course, what about glib?  i.e. do we have to
have some "table" like this we use at configure time?

    glibversion guileversion gwrap-glib-soname
       1.2         1.4              1
       1.2         1.6              2
       2.0         1.4              3
       2.0         1.6              4

and of course, what room does this leave for changing the soname if I
need to make normal binary incompatible changes to the actual
libgwrap-guile API, and what happens if the library depends on 4
sub-libraries, each with two recent versions likely to be in service
on any given platform, do we have a table with 16 sonames?

Unless I'm misunderstanding, this all still seems *very* fragile to
me, but without a major unix/C/libc/ld.so overhaul or some other form
of improbable magic, it's not looking like we have many alternatives.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4