From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Neil Jerram Newsgroups: gmane.lisp.guile.devel Subject: Re: Policies about shared libs (directly affects .deb packaging) Date: 12 Nov 2002 22:30:11 +0000 Sender: guile-devel-admin@gnu.org Message-ID: 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 1037141349 8376 80.91.224.249 (12 Nov 2002 22:49:09 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Tue, 12 Nov 2002 22:49:09 +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 18BjqF-0002Ax-00 for ; Tue, 12 Nov 2002 23:49:07 +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 18BjoO-0003jl-00; Tue, 12 Nov 2002 17:47:12 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 18Bjeu-0007S3-00 for guile-devel@gnu.org; Tue, 12 Nov 2002 17:37:24 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 18Bjer-0007RM-00 for guile-devel@gnu.org; Tue, 12 Nov 2002 17:37:23 -0500 Original-Received: from mail.uklinux.net ([80.84.72.21] helo=s1.uklinux.net) by monty-python.gnu.org with esmtp (Exim 4.10) id 18Bjeq-0007Ql-00 for guile-devel@gnu.org; Tue, 12 Nov 2002 17:37:20 -0500 Original-Received: from laruns.ossau.uklinux.net (bts-1002.dialup.zetnet.co.uk [194.247.51.234]) by s1.uklinux.net (8.11.6/8.11.6) with ESMTP id gACMbEm19775; Tue, 12 Nov 2002 22:37:14 GMT Original-Received: from laruns.ossau.uklinux.net.ossau.uklinux.net (localhost [127.0.0.1]) by laruns.ossau.uklinux.net (Postfix on SuSE Linux 7.2 (i386)) with ESMTP id EF97CDC12C; Tue, 12 Nov 2002 22:30:11 +0000 (GMT) Original-To: Rob Browning In-Reply-To: <87lm3yecxx.fsf@raven.i.defaultvalue.org> Original-Lines: 56 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 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:1693 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:1693 >>>>> "Rob" == Rob Browning writes: Rob> 1) We may never change the major number of any lib during a stable Rob> release cycle. 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? Otherwise, this seems fine. I strongly support restricting what we can change within a stable release. (Partly because it's right for developers/users, partly because I don't like parallel development and there are lots of goodies in 1.7 that I want to see released :-) Just to be sure, though, what are the changes that should cause us to increment the major number of a library? Rob> 2) We must change the major number of *all* libs with every new Rob> guile release, i.e. when we go from 1.6 to 1.8. This seems self-evident. If there's a library in the distro that is so non-dependent on libguile that this would be burdensome, why is that library in the core distro? 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)") ? Rob> If we don't want to promise to accommodate restrictions (1) and (2), Rob> then guile will have to be comprised of at least: Rob> Package: guile-1.6 Rob> Package: libguile-12 Rob> Package: libqthreads-12 Rob> Package: libguile-ltdl-1 Rob> Package: libguilereadline-v-12 Rob> Package: libguile-srfi-srfi-4-v-1 Rob> Package: libguile-srfi-srfi-13-14-v-1 Rob> Package: guile-1.6-dev Rob> Package: guile-1.6-doc Rob> During packaging I will have to be careful to split up the .scm files Rob> appropriately among the various lib packages, and we'll have to be Rob> very careful here upstream not to create inter-dependencies among the Rob> non-libguile .scm files that could cause problems across releases of Rob> different versions of a given lib. This sounds a lot like hard work, and probably a worse nightmare than having your proposed restrictions. Neil _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel