From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Rob Browning Newsgroups: gmane.lisp.guile.devel Subject: Re: Policies about shared libs (directly affects .deb packaging) Date: Tue, 12 Nov 2002 17:13:18 -0600 Sender: guile-devel-admin@gnu.org Message-ID: <87r8dqbcvl.fsf@raven.i.defaultvalue.org> References: <87lm3yecxx.fsf@raven.i.defaultvalue.org> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1037145078 21857 80.91.224.249 (12 Nov 2002 23:51:18 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Tue, 12 Nov 2002 23:51:18 +0000 (UTC) Cc: guile-devel@gnu.org Return-path: Original-Received: from monty-python.gnu.org ([199.232.76.173]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 18BkoO-0005gL-00 for ; Wed, 13 Nov 2002 00:51:16 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10) id 18Bkns-0008Jw-00; Tue, 12 Nov 2002 18:50:44 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 18BkDl-0005mq-00 for guile-devel@gnu.org; Tue, 12 Nov 2002 18:13:25 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 18BkDh-0005m8-00 for guile-devel@gnu.org; Tue, 12 Nov 2002 18:13:24 -0500 Original-Received: from n66644228.ipcdsl.net ([66.64.4.228] helo=defaultvalue.org) by monty-python.gnu.org with esmtp (Exim 4.10) id 18BkDf-0005lj-00 for guile-devel@gnu.org; Tue, 12 Nov 2002 18:13:20 -0500 Original-Received: from raven.i.defaultvalue.org (raven.i.defaultvalue.org [192.168.1.7]) by defaultvalue.org (Postfix) with ESMTP id 79772C4D8; Tue, 12 Nov 2002 17:13:18 -0600 (CST) Original-Received: by raven.i.defaultvalue.org (Postfix, from userid 1000) id 4E7CF1D500; Tue, 12 Nov 2002 17:13:18 -0600 (CST) Original-To: Neil Jerram In-Reply-To: (Neil Jerram's message of "12 Nov 2002 22:30:11 +0000") User-Agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/21.2 (i386-pc-linux-gnu) Errors-To: guile-devel-admin@gnu.org X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Developers list for Guile, the GNU extensibility library List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.lisp.guile.devel:1695 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:1695 Neil Jerram writes: > The one problem scenario would be a lib in the core distro that wanted > to change much faster than the rest. In this case, could we unbundle > just that one library? In other words, if we try out these > restrictions for a while and they don't work for some library, is > there a recovery path? I'd have to think carefully to be sure, but I *think* that might be OK. If we unbundle a lib, then the next micro revision of guile-X.Y-libs would come out along with a libguile-foo-Z package. This package would Depend on guile-X.Y-libs (>= new-revision), but would also have to "Conflicts: guile-X.Y-libs" and "Replaces: guile-X.Y-libs". One drawback is that this could get messy in the control file over time if we do it very often. > Just to be sure, though, what are the changes that should cause us > to increment the major number of a library? libFOO's major number would need to be bumped given any changes that could break any app or lib that used to be linked against the previous copy of libFOO, and as I mentioned later, I think that in our case it may sometimes be more than just the .c files since some lib's corresponding .scm files could change their semantics in ways that break backward compatibility wrt the *C* API, even if the C code hadn't changed (see your and my comments below). Note that this is only true if the .c code is allowed to call functions or use variables provided by the .scm files (or perhaps pass them out as data). If we wanted to make the restriction that that's not allowed, that .c code may not depend on .scm files, then it should only be changes to the .c files that can affect a lib's binary compatibility. (Actually it's the headers too since of course they can actually embed code in *other* libs or apps). The libtool info pages have a semi-decent explanation of why/when you have to bump the major soname, though they call it the "interface number", and as I recall they may not specifically address the fact that even if the lib in question's code doesn't change, if that lib re-exports data structures or functions from a sub-lib, then the lib must to bump its soname whenever anything in the sub-lib changes "in a relevant way" that the lib passes on via its API to its clients. The above is my current understanding -- so everyone, please correct me if I'm wrong. > Rob> No matter what we do, any time we change any .scm file, we have to > Rob> make sure that it doesn't directly or indirectly alter the API of > Rob> *any* lib inside guile in a way that requires that lib to change its > Rob> major number. > > What about scm_eval_string("(proc-whose-behaviour-just-changed)") ? Good question, and one I think we need to answer, or even more specifically imagine libguile-foo with: SCM scm_public_function_do_foo () { return scm_eval_string ("(make-a-foo)"); } I've wondered about this for a while, and I think I talked to Marius about it, but I can't recall what if anything was decided. > This sounds a lot like hard work, and probably a worse nightmare than > having your proposed restrictions. It's not actually a ton of work since I've got a decent amount of it automated, but it *is* more a more complicated arrangement for people to understand when coming to guile. It may, however, be the thing we need to do... And on a somewhat related note, I do worry a little that we may be setting ourselves up for some unpleasant impressions from the broader unix community with our library approach, though I don't have any good solutions that aren't going to aggravate someone. Our current approach makes sense, but imagine we do become a lot more popular. Is the broader non-scheme, non-guile community going to be tolerant of the placement of hundreds of libguile-* libraries into /usr/lib? If we ever get to even a fraction of the number of add-on packages in CPAN, that's where we'd be headed. Not sure it matters, and I'm not saying we should change our behavior, but I wanted to make sure everyone's thought about some of the these potential "mostly non-technical" issues. It's my impression that perl and python, etc. don't suffer from this nearly so much b/c they don't support/encourage the direct linking we do. Actually let me rephrase that -- they *do* suffer from the "bazillion small packages problem", i.e. search debian for lib*-perl packages, but they don't suffer from the "bazillion files in /usr/lib" issue. FWIW. -- Rob Browning rlb @defaultvalue.org, @linuxdevel.com, and @debian.org Previously @cs.utexas.edu _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel