Re: GnuCash 1.7.6 release delayed
- To: Chris Lyttle <chris@wilddev.net>
- Cc: debian-devel@lists.debian.org, guile-devel@gnu.org
- Subject: Re: GnuCash 1.7.6 release delayed
- From: Rob Browning <rlb@defaultvalue.org>
- Date: Thu, 19 Dec 2002 16:13:03 -0600
- Message-id: <[🔎] 87of7hd5e8.fsf@raven.i.defaultvalue.org>
- In-reply-to: <1040203058.1600.9.camel@meher.wilddev.net> (Chris Lyttle's message of "18 Dec 2002 01:17:38 -0800")
- References: <1040018800.9237.2.camel@meher.wilddev.net> <87smwy5tka.fsf@raven.i.defaultvalue.org> <1040025408.922.13.camel@meher.wilddev.net> <87y96p4z6o.fsf@raven.i.defaultvalue.org> <1040183719.1596.0.camel@meher.wilddev.net> <87of7jkgha.fsf@raven.i.defaultvalue.org> <1040203058.1600.9.camel@meher.wilddev.net>
Chris Lyttle <chris@wilddev.net> 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
Reply to: